Simon Urbanek <[EMAIL PROTECTED]> writes: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 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 ;) ;)
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.[I'm not quite sure what you're pointing to with the "quite recent code" remark. Could you be more specific?]
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 ...).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.
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.
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.We could (I [...] manipulator (e.g. bison can be set to generate a set of parse tables), but multithreading seems much more straightforward.
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
[EMAIL PROTECTED] http://simon.urbanek.info
______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
