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 <[email protected]> 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
