> From: Martin Maechler <maechler@stat.math.ethz.ch>
>
> >>>>> "Duncan" == Duncan Murdoch
<murdoch@stats.uwo.ca>
> >>>>> on Sun, 28 Nov 2004 10:25:24 -0500 writes:
>
> Duncan> <........>
> Duncan> <........>
>
> Duncan> We already have code to source() from the clipboard, and it
could
> Duncan> address the problems above, but:
>
> Duncan> - Source with echo=T doesn't echo, it deparses, so some
comments are
> Duncan> lost, formatting is changed, etc.
>
> yes, and we would have liked to have an alternative "source()"
> for a *very* long time...
> Examples where I "hate" the non-echo (i.e. the loss of all
> comments and own-intended formatting) is when you use it for
> demos, etc, notably in R's own demo() and example() functions.
>
> But to do this might be more tricky than at first thought:
> Of course you can readLines() the source file and writeLines()
> them to whatever your console is. The slightly difficult thing
> is to "see" which junks to ``send to R'' , i.e. to
parse() and eval().
> The basic problem seems to see when expressions are complete.
>
> Maybe we should / could think about enhancing parse() {or a new
> function with extended behavior} such that it would not only
> return the parse()d expressions, but also indices (byte or even
> line counters) to the source text, indicating where each of the
> expression started and ended.
>
> That way I could see a way to proceed.
The other problems with source() are (1) reading from stdin so that
one can create self contained files. (2) Even if possible, it
would also be nice to be able to put the data at the end of
the file so the code is not broken up by potentially large
stretches of data.
Number (1) can be addressed by pasting the output of dput
into your file but its not pretty. A workaround addressing
both (1) and (2) is in:
https://stat.ethz.ch/pipermail/r-help/2003-June/033622.html
Perhaps these two considerations could be taken into account
if source() is being revisited.
--- On Tue 11/30, Martin Maechler < maechler@stat.math.ethz.ch > wrote:
From: Martin Maechler [mailto: maechler@stat.math.ethz.ch]
To: murdoch@stats.uwo.ca
Cc: r-devel@stat.math.ethz.ch
Date: Tue, 30 Nov 2004 12:51:12 +0100
Subject: [Rd] a better "source(echo=TRUE)" {was "....how to
pause...."}
>>>>> "Duncan" == Duncan Murdoch
<murdoch@stats.uwo.ca><br>>>>>> on Sun, 28 Nov
2004 10:25:24 -0500 writes:<br><br> Duncan>
<........><br> Duncan> <........><br><br>
Duncan> We already have code to source() from the clipboard, and it
could<br> Duncan> address the problems above,
but:<br><br> Duncan> - Source with echo=T doesn't echo, it
deparses, so some comments are<br> Duncan> lost, formatting is
changed, etc.<br><br>yes, and we would have liked to have an
alternative "source()"<br>for a *very* long
time...<br>Examples where I "hate" the non-echo (i.e. the loss
of all<br>comments and own-intended formatting) is when you use it
for<br>demos, etc, notably in R's own demo() and example()
functions.<br><br>But to do this might be more tricky than at first
thought:<br>Of course you can readLines() the source file and
writeLines()<br>them to whatever your console is. The slightly difficult
thing<br>is to "see" which junks to ``send to R'' , i.e.
to parse() and eval().<br>The basic problem seems to see when expressions
are complete.<br><br>Maybe we should / could think about enhancing
parse() {or a new<br>function with extended behavior} such that it would
not only<br>return the parse()d expressions, but also indices (byte or
even<br>line counters) to the source text, indicating where each of
the<br>expression started and ended.<br><br>That way I could
see a way to proceed.<br><br>Martin<br><br>
Duncan> <........><br> Duncan>
<........><br><br>______________________________________________<br>R-devel@stat.math.ethz.ch
mailing list<br>https://stat.ethz.ch/mailman/listinfo/r-devel<br>
