[Rd] about REPL and loops in general ...

[Simon Urbanek]

On Friday, August 29, 2003, at 12:11  PM, Peter Dalgaard BSA wrote:

> Simon Urbanek <Simon.Urbanek at math.uni-augsburg.de> writes:
>
>> I think that something along the lines of a "light" REventLoop (i.e.
>> [...]
>> tricks. So, are there plans to replace the current REPL soon?
>> (preferably in 1.8 ;)). If not, what are the reasons?
>
> The main reason is that we can't seem to get it right... It would be a
> very welcome thing to have in R-2.0 (Planned: Apr.2004) in some form or
> another. Or 1.8 if you can just send us the perfect solution by next
> week, for all platforms, please ;) ;)
Hmm.. I got an AIX, Sun 5.8, FreeBSD x86, Linux x86, Windows and Darwin 
here to test on - does that count as "all platforms" ? ;)

> [I'm not quite sure what you're pointing to with the "quite recent
> code" remark. Could you be more specific?]
The most recent thing I had in mind was the #ifdefs added for Aqua, but 
in general both the comments concerning REPL and Duncan's REventLoop 
pages state summer 2002 as the last update, so I wondered where the 
development is heading.

> One particular issue that has come up again recently is that people
> want to run REPL loops on connections (e.g. sockets). With the current
> implementation, we can't handle incomplete input, and the only easy
> fix would be to buffer up and reparse from start of expression at
> every end of line, as we currently do on std. input.
I noticed that, but is there anything wrong with it? The re-parsing is 
basically necessary for user GUIs only - and I don't think the parsing 
time is an issue there. If commands are sent via 
socket/file/application/whatever where parsing time matters then the 
other side usually knows what the complete block is (if it does not .. 
well, then it's very likely an user GUI again ...).

Using the callback handlers I sketched (and REventLoop uses something 
similar) has the advantage that the application could do whatever it 
needs - run a single R command using C API, parse and evaluate in one 
shot or call this 'sequential parse function'. We could also easily 
provide a 'handler' which works on fds (socket/console...) and runs a 
simple REPL like the current one.

> We could (I
> [...]
> manipulator (e.g. bison can be set to generate a set of parse tables),
> but multithreading seems much more straightforward.
Yes, but that would mean to shift the multi-threading further into R 
which (so I was told - I didn't look at the parser myself) is a rather 
complex task. As I explained above I'm not sure we really need that.

The benefit of using separate structures for the parser (which would 
also allow multi-threading) would be that especially with large code 
the source could be passed in chunks. But IMHO I believe this is 
independent of the REPL issue in a sense that improved main R loop can 
easily accommodate improved parser - much more easily even, especially 
since now each module that replaces REPL relies on the current state 
whereas the new R loop would make it possible to improve the parser at 
a later stage without the need to modify the modules.


---
Simon Urbanek
Department of computer oriented statistics and data analysis
University of Augsburg
Universitätsstr. 14
86135 Augsburg
Germany

Tel: +49-821-598-2236
Fax: +49-821-598-2200

Simon.Urbanek at Math.Uni-Augsburg.de
http://simon.urbanek.info