[R] eval(parse(text vs. get when accessing a function

[Ramon Diaz-Uriarte]

On 1/6/07, Thomas Lumley <tlumley at u.washington.edu> wrote:
> On Fri, 5 Jan 2007, Ramon Diaz-Uriarte wrote:
>
> > I see, this is direct way of dealing with the problem. However, you first need
> > to build the f list, and you might not know about that ahead of time. For
> > instance, if I build a function so that the only thing that you need to do to
> > use my function g is to call your function "f.something", and then pass
> > the "something".
> >
> > I am still under the impression that, given your answer,
> > using "eval(parse(text" is not your preferred way.  What are the possible
> > problems (if there are any, that is). I guess I am puzzled by "rethink
> > whether that was really the right question".
> >
>
> There are definitely situations where parse() is necessary or convenient,
> or we wouldn't provide it. For example, there are some formula-manipulation problems where it really does seem to be the best solution.
>
> The point of my observation was that it is relatively common for people to ask about parse() solutions to problems, but relatively rare to see them in code by experienced R programmers.  The 'rethink the question' point is that a narrowly-posed programming problem may suggest parse() as the answer, when thinking more broadly about what you are trying to do may allow a completely different approach [the example of lists is a common one].
>

Yes, the general thing I am trying to do do ---see my response to Greg
Snow for details--- has been done before. And I looked at code from
more experienced programmers, such as David Meyer's tune in e1071. I
think one of the reasons David is using do.call is that he allows to
use arbitrary functions, whereas I do not (currently) need that
functionality.

Thus, instead of calling "do.call(whatever)" I can call
"internalGeneSelect". And, when reading my code, or debugging, it is
easier for me to quickly decode "internalGeneSelect" ("oh, yes,
calling the geneSelection function") than decode "do.call".

But my "internalGeneSelect" depends on "eval(parse(text = " and that
is where my doubts started.

Because of this thread, though, I am actually starting to think I
should go ahead and use "do.call", because it will make life simpler
if someone (including myself) decides to extend the code.  I guess
this can be a case of "thinking more broadly".


> The problem with eval(parse()) is not primarily one of speed.  A problem with parse() is than manipulating text strings is easy to mess up, since text has so much less structure than code. A problem with eval() is that it is too powerful -- since it can do anything, it is harder to keep track of what it is doing.
>

Yes, I understand that. In my specific case, though, there is quite a
high degree of structure on the text used. And I felt that do.call was
also very powerful (and I've messed with "..." in similar situations
in the past).


> In one sense this is just a style issue, but I still think my comment is good advice. If you find yourself wanting to use parse() it is a good idea to stop and think about whether there is a better way to do it. Often, there is. Sometimes, there isn't.
>

Thanks for your comments. I think here "do.call" might actually be the
way to go.


Best,

R.





>
>         -thomas
>
> Thomas Lumley                   Assoc. Professor, Biostatistics
> tlumley at u.washington.edu        University of Washington, Seattle
>
>
>


-- 
Ramon Diaz-Uriarte
Statistical Computing Team
Structural Biology and Biocomputing Programme
Spanish National Cancer Centre (CNIO)
http://ligarto.org/rdiaz