[Rd] a better

[Gabor Grothendieck]

> From:   Martin Maechler <maechler at stat.math.ethz.ch>
>  
> >>>>> "Duncan" == Duncan Murdoch <murdoch at 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 at stat.math.ethz.ch > wrote:
From: Martin Maechler [mailto: maechler at stat.math.ethz.ch]
To: murdoch at stats.uwo.ca
     Cc: r-devel at 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 at 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 at stat.math.ethz.ch mailing list<br>https://stat.ethz.ch/mailman/listinfo/r-devel<br>