Re: [Bug-apl] Command::process_line breakup

[Juergen Sauermann]

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 <address@hidden> 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