From duncan@research.bell-labs.com  Thu Jun 20 12:58:05 2002
From: duncan@research.bell-labs.com (Duncan Temple Lang)
Date: Thu, 20 Jun 2002 07:58:05 -0400
Subject: a version of source() which keeps comments ?
In-Reply-To: <Pine.LNX.4.31.0206201234540.18504-100000@gannet.stats>; from ripley@stats.ox.ac.uk on Thu, Jun 20, 2002 at 12:43:26PM +0100
References: <x2660eryar.fsf@biostat.ku.dk> <Pine.LNX.4.31.0206201234540.18504-100000@gannet.stats>
Message-ID: <20020620075805.B18932@jessie.research.bell-labs.com>

ripley@stats.ox.ac.uk wrote:
> On 20 Jun 2002, Peter Dalgaard BSA wrote:
> 
> > Martin Maechler <maechler@stat.math.ethz.ch> writes:
> >
> > > I'd like to have this to be used in, e.g.,
> > > demo() and example().
> > >
> > > Currently, source() parse()s the entire file and then evaluates
> > > expression by expression. ``Of course'',  parse() already loses
> > > the comments.
> > >
> > > An (much slower) alternative might be to the readLine() the
> > > file, echo what we read,
> > > and try to parse() ``the current chunk''.
> > > when parse() fails (when the current expression is incomplete),
> > > we silently read the next line, etc, until the expression is complete and hence
> > > parse() succeeds, then we eval() and print().
> > >
> > > What do people think?
> > >
> > > Would there be volunteers to write this?
> > > [I think it should finalize as an optional argument to source(),
> > >  but for experimentation it might be easier to try with a
> > >  function  sourceLinewise(.)
> > > ].
> >
> > Historically, this is what source() should have done all the time if
> > it were to be in keeping with other Unix programs (shift input from
> > stdin temporarily). The source() that we have is really "evaluate
> > file". I don't think we can source() an infinite stream like a pipe or
> > a socket, can we?
> >
> > Actually, I think it can be done with a little careful file descriptor
> > switching. (Turn of readline processing, etc., switch stdin to file,
> > run till eof or error, switch back and reestablish readline.) We'd
> 
> Rather, connection-switching.  The Green book describes sink() as being
> capable of switching the input connection, but it isn't like that
> in any version of S-PLUS I have ever seen.  I haven't thought through the
> ramifications.


And I'll make a further distinction (again based on S4 and hopefully
very soon to be R): specifically we should be able to switch `reader'
on a connection. In S4 one can associate an S function with a
connection so that when input becomes available on the connection's
file descriptor, the S function is invoked. This is a reader.

We can support this on Unix using the AddInputHandler, but we need to
add a method to the C level connection structure to get its file
descriptor.  Additionally, I'm in the middle of experimenting with
different event loops (e.g. those of Tcl/Tk and Gtk) and allowing them
to be run as the main R event loop. We get timers (monitors in S4) and
file descriptor notification for "free" in both of these.  I intend to
have an RFC for this and an implementation for sliding it into R next
week. (Anyone's welcome to the code now if they are interested.)

> 
> 
> > still have the reparse-on-incomplete thing, since that also happens on
> > stdin -- something I suspect isn't necessary, but it takes a fairly
> > hard look at the grammar itself to find out.
> >
> > (This kind of stuff has long been on my might-do list of projects,
> > along with (re)fixing the comment issue and providing better
> > information on parse/eval errors. I'd better not feel possessive about
> > the ideas...)
> >
> > --
> >    O__  ---- Peter Dalgaard             Blegdamsvej 3
> >   c/ /'_ --- Dept. of Biostatistics     2200 Cph. N
> >  (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
> > ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
> > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> > r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> > Send "info", "help", or "[un]subscribe"
> > (in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
> > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
> >
> 
> -- 
> Brian D. Ripley,                  ripley@stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272860 (secr)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

-- 
_______________________________________________________________

Duncan Temple Lang                duncan@research.bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-3217
700 Mountain Avenue, Room 2C-259  fax:    (908)582-3340
Murray Hill, NJ  07974-2070       
         http://cm.bell-labs.com/stat/duncan
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


a version of source() which keeps comments ?
Duncan Temple Lang