RE: [Rd] a better

From: Gabor Grothendieck <ggrothendieck_at_myway.com>
Date: Tue 30 Nov 2004 - 23:20:37 EST

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

>>>>> "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_at_stat.math.ethz.ch mailing list<br>https://stat.ethz.ch/mailman/listinfo/r-devel<br>

______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue Nov 30 23:36:05 2004

This archive was generated by hypermail 2.1.8 : Wed 01 Dec 2004 - 01:12:29 EST