Hi Elias and Peter,
first of all, I am planning to put the commands )LOAD, )SAVE, ... into a
separate
function. That will replace lines 72-132 in Command.cc by a call to a
new function.
The remaining lines cannot be broken down further - they are the "main
loop" of APL
Regarding terminal I/O there are only 3 functions for getting user input:
*Input::get_line(),**
**Input::get_quad_cr_line(old_prompt)**, and**
**Input::get_user_line_nabla(&prompt)**
*
The first function is for "normal" user input. The second implements the
rather
specific behavior of ? (overriding the prompt, ?PR etc) and the third is
for the ?-editor
(printing [line] prompts).
If you can sacrifice one of these special cases, for example
*get_user_line_nabla() *if you
have your own editor then the number of functions can be reduced further
and the input handling
becomes even simpler.
All that is needed for a new environment is to rewrite these functions.
/// Jürgen
On 06/05/2014 07:38 PM, Peter Teeson wrote:
Well this is an opportunity to bring up something that has been on my
mind for some time.
My feeling is that a better way to deal with the I/O issue is to have
an abstract Class ( or Classes) from which
the various I/O implementations can inherit. e.g. Class Input, Class
Output or Class InputOutPut.
The present implementation of a terminal / command line interface
would be the default and be one example.
In Xcode I have run into issues trying to make a simple wrapper for
GNU APL.
Not the least of these is avoiding terminal control codes which I
presently do with apl launch options - a bit crufty.
Mentally I have a picture of the interpreter as a (potentially)
embeddable item with a full duplex I/O channel.
It is the interpreter that is the crucial thing that does the work of
solving. The I/O is just the Microphone and Speaker.
Then one can use (or implement) the I/O mechanism of one's choice.
Of course there must be constraints on what is acceptable input (must
be characters and must be in quadAV?).
I submit that this approach is preferable versus adding special case
code (which is never ending) and
IMHO neither elegant nor desirable even if it is practical. :-}
Just my 2¢ FWIW.
much respect to everyone.
Peter
On 2014-06-05, at 10:49 AM, Elias Mårtenson <loke...@gmail.com
<mailto:loke...@gmail.com>> wrote:
In the Android version that I have started working on, am I not going
for a plain text-based I/O model like the normal GNU APL session.
This is because terminal-oriented sessions are quite cumbersome to
work with on a small mobile device.
Instead, I intend to be a bit more clever when rendering results,
being able to do things like collapsing parts of the array, doing
searches, panning them around with the touchscreen. I haven't
actually implemented any of this yet, but those are my rough ideas.
Anyhow, this means that the mainloop looks significantly different
compared to the normal version. And what I realise is happening is
that I am reimplementing most of Command::process_line. I can't
really re-use anything in it because it's such a big single method.
My question is: Would it be possible to break it up into smaller
functions that I can call from the Android interaction loop? Ideally,
I would like to be able to pass a string into a function for
evaluation (taking account all the stuff like the SI stack etc) and
simply return a Token that represents the result of the evaluation.
I'm perfectly fine with having the Error being thrown in case of error.
Commands can be handled separately of course (I intend to present
those in a menu most likely).
Would this be doable?
Regards,
Elias
