a version of source() which keeps comments ?

[ripley@stats.ox.ac.uk]

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.


> 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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._