Thanks for the suggestions, Gabor!
On 03-Oct-07 12:52:51, Gabor Grothendieck wrote:
> 1. you could place the commands in a file and source the file each
> time you want to run it or it might be good enough to place it on the
> clipboard and then just do source("clipboard")
Using the file solution is a bit cumbersome for the sort of
situation I was referring to. Basically, I'll be using R
exploratively, so entering various sequences of commands.
Every so often I will think "Ah, I'll probably need that
block again".
Since there will usually be several of these, the clip-board
solution wouldn't work.
In fact, the way I usually work for this kind of thing is
to have a "side-window" in which I'm editing a text file,
and into which I write the R commands I want to keep track
of (a bit like a rather random partial history). Then, if
I want to re-use any of these, I can highlight a block with
the mouse and paste it into the R console.
So it's a bit like your file solution. This text file can
also subsequently be used as a source of raw material for
a properly constructed batch file, which is a bonus.
However, there are two potential inconveniences:
1) pasting with the mouse can be error prone, if one has
a "dexterity lapse";
2) One may end up scrolling back and forth in the file
groping for "that sequence" -- and may end up with
one which looks like the one you want, but in fact
is different in some essential detail. I've also
had that problem where there are many commands like
X<-source("AUX12NBX4G001.csv")
where choice of filenames has nothing to do with me...
Indeed, a "function" replacement of the above could
look like
sNBX4<-function(){X<<-source("AUX12NBX4G001.csv")}
if I know that "NBX4" is sufficient to make it unique.
For those reasons, I had the idea of the "named block"
which I realise, now you point it out, is really a macro.
I'm old enough to have encountered R News 1/3, but now
I re-read Thomas's article I realise that it must have
been over my head at the time! Also, it looks as though
writing a defmacro for an arbitrary block of code could
involve careful thought. It's not as straightforward as
block1 <- function(){The Block Of Code}
Thanks,
Ted.
> 2. Thomas Lumley's defmacro in R News 1/3 could be used
>
> Neither of these two require that you do anything special to write back
> the variables.
>
> Although not specifically a solution the problem you pose
> look at ?within (new in R 2.6.0) just in case.
>
> On 10/3/07, Ted Harding <[EMAIL PROTECTED]> wrote:
>> Hi Folks,
>>
>> The question I'm asking, regarding the use of function
>> definitions in the context described below, is whether
>> there are subtle traps or obscure limitations I should
>> watch out for. It is probably a rather naive question...
>>
>> Quite often, one has occasion to execute interactively
>> a lot of R commands in which, from time to time, one has
>> occasion to repeat exactly a sequence of commands which
>> one has entered earlier. These commands would only refer
>> to variables which have been created at the "top level" of
>> the program and which exist at the time the sequence of
>> commands is entered.
>>
>> So it would be convenient to refer to such a sequence of
>> commands as a "named block" -- just give its name, and
>> they are executed.
>>
>> In my experiments, wrapping the first occurrence of such
>> a sequence in a function definition seems to work, e.g.
>> the first time they are needed:
>>
>> block1 <- function(){
>> sequence of commands that you would have enetered
>> for execution at this point
>> }
>> block1()
>>
>> This first call to block1() seems to work OK, in my tests,
>> PROVIDED, of course,
>> a) The variables it uses and assigns to exist already;
>> b) all internal "<-" assignments are written "<<-".
>> Then, of course, the next time that block is needed,
>> you can call block1() again.
>>
>> But can this usage of function definition give rise
>> to problems? R scoping can be a bit tricky! And I
>> think I am perhaps being naive ...
>>
>> (It is not intended that such blocks of code would include
>> function definitions).
>>
>> OR: Is there a more "kosher" way to do this kind of thing ... ?
>>
>> With thanks,
>> Ted.
>>
>> --------------------------------------------------------------------
>> E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
>> Fax-to-email: +44 (0)870 094 0861
>> Date: 03-Oct-07 Time: 12:56:42
>> ------------------------------ XFMail ------------------------------
>>
>> ______________________________________________
>> R-help@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>>
>
> ______________________________________________
> R-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
--------------------------------------------------------------------
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 03-Oct-07 Time: 15:08:54
------------------------------ XFMail ------------------------------
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
