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

From: Ramon Diaz-Uriarte <rdiaz02_at_gmail.com>
Date: Sat 06 Jan 2007 - 14:32:43 GMT

On 1/6/07, jim holtman <jholtman@gmail.com> wrote:
> I agree with what you are saying. That is the reason I have "What is the
> problem you are trying to solve" on my signature.
>
> The other way of saying that is "Tell me what you want to do, not how you
> want to do it."
>

Point taken: I did not provide enough detail. (But then, with the detail I provided in my reply to Greg Snow's answer, I think most people will have not looked at the long email, which means I would not have been getting as much useful feedback :-).

R.

>
> On 1/5/07, Thomas Lumley <tlumley@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].
> >
> > 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.
> >
> > 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.
> >
> >
> > -thomas
> >
> > Thomas Lumley Assoc. Professor, Biostatistics
> > tlumley@u.washington.edu University of Washington, Seattle
> >
> > ______________________________________________
> > R-help@stat.math.ethz.ch 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.
> >
>
>
>
> --
> Jim Holtman
> Cincinnati, OH
> +1 513 646 9390
>
> What is the problem you are trying to solve?

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

______________________________________________
R-help@stat.math.ethz.ch 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.
Received on Sun Jan 07 03:24:56 2007

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Sat 06 Jan 2007 - 16:30:25 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-help. Please read the posting guide before posting to the list.