> From: Martin Maechler <[EMAIL PROTECTED]>
>
> >>>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
> >>>>> 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 < [EMAIL PROTECTED] > wrote:
From: Martin Maechler [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Tue, 30 Nov 2004 12:51:12 +0100
Subject: [Rd] a better "source(echo=TRUE)" {was "....how to pause...."}
>>>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]><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>[EMAIL PROTECTED]
mailing list<br>https://stat.ethz.ch/mailman/listinfo/r-devel<br>
______________________________________________
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
