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

[Peter Teeson]

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