[Rd] about REPL and loops in general ...
Simon Urbanek
Simon.Urbanek at math.uni-augsburg.de
Fri Aug 29 15:39:16 MEST 2003
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
More information about the R-devel
mailing list