[R] R 'function' as "subroutine"

(Ted Harding) Ted.Harding at manchester.ac.uk
Wed Oct 3 16:08:56 CEST 2007


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 <Ted.Harding at manchester.ac.uk> 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) <Ted.Harding at manchester.ac.uk>
>> Fax-to-email: +44 (0)870 094 0861
>> Date: 03-Oct-07                                       Time: 12:56:42
>> ------------------------------ XFMail ------------------------------
>>
>> ______________________________________________
>> R-help at 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 at 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) <Ted.Harding at manchester.ac.uk>
Fax-to-email: +44 (0)870 094 0861
Date: 03-Oct-07                                       Time: 15:08:54
------------------------------ XFMail ------------------------------



More information about the R-help mailing list