Re: [R] Understanding eval

From: Charilaos Skiadas <>
Date: Sun, 23 Dec 2007 22:30:16 -0500

On Dec 23, 2007, at 9:21 AM, Duncan Murdoch wrote:

> On 23/12/2007 9:15 AM, Duncan Murdoch wrote:
>> On 22/12/2007 5:45 PM, Charilaos Skiadas wrote:

>>> On Dec 22, 2007, at 4:44 PM, Duncan Murdoch wrote:
>>>>> 5) eval then creates the environment where this evaluation
>>>>> will take place. It does that by creating an environment
>>>>> containing the frame "a=5", and with enclosing environment
>>>>> the parent frame of foo, which is bar's environment.
>>>>> 6) So, as I understand it, the symbol "er" is going to now be
>>>>> evaluated in an environment where a is set to 5 and er is set
>>>>> to a, along with whatever is in the user's workspace.
>>>> I think this part is wrong. A better description is:
>>>> er is going to be evaluated in an environment where a is set to
>>>> 5. The parent of that environment is the bar evaluation frame,
>>>> where er is set to be a promise to evaluate a in the global
>>>> environment.
>>>>> 7) So the first step now is looking up a definition for er.
>>>>> Nothing is found in the current frame, so the evaluation
>>>>> proceeds to bar's environment, where the association "er=a"
>>>>> is found, so er is replaced by a.
>>>> No, at this point an attempt is made to force the promise.
>>>> Promises have their own associated environments, and that's
>>>> where the evaluation takes place. In the case of the er
>>>> object, the associated environment is the one where bar(a) was
>>>> called, i.e. the global environment.
>>>>> 8) Now, and perhaps this is where I misunderstand things, the
>>>>> lookup for a will take place. My thinking was that the lookup
>>>>> would start from the evaluation environment that eval
>>>>> created, and hence would locate the a=5 value. But this is
>>>>> clearly not what happens.
>>>>> Anyway, hope someone will correct me where I'm wrong, and
>>>>> explain to me what I am doing wrong, and ideally how to
>>>>> diagnose such things.
>>>> Diagnosing things like this is hard. Promises are very
>>>> difficult things to look at: as soon as you try to do anything
>>>> with them they get evaluated, and there's no way in R code to
>>>> display them without that.
>>>> You can use substitute() to extract the expression part, but
>>>> there's no way to extract the environment part. Maybe there
>>>> should be, but it's tricky to get the semantics right. If the
>>>> function environment() worked to extract the environment of a
>>>> promise, then all sorts of code would fail where I really
>>>> wanted to evaluate the arg before extracting the environment.
>>> Thank you Duncan, for the very clear explanation.
>>> Ok, so the substitute "breaks through" the promise of expr,
>>> returning as a language object the promise of er, and there's no
>>> easy way to break through that. I ended up with the following,
>>> somewhat uglier than I wanted, code, which seems to do what I
>>> need in this case, and hopefully will still work in the more
>>> general case I want it to. The idea was to break through the er
>>> promise in bar, before sending it over to foo. Then foo receives
>>> simply an expression, which it can then evaluate. Though I seem
>>> to have had to work a bit harder on that part than I expected
>>> to. Perhaps there's an easier way? Or things that can go
>>> seriously wrong with this way?
>>> foo <- function(fr, expr) {
>>> ..obj <- list(.=fr)
>>> ..expr <- substitute(expr)
>>> ..txt <- parse( text=paste("substitute(",..expr,")") )
>> I think you want
>> ..txt <- parse( text=paste("substitute(",deparse(..expr),")") )
>> here, but it's even better not to go through the deparse-parse cycle:
>> ..txt <- bquote( substitute( .(..expr) ) )
>> The main thing that could go wrong ...
> Sorry, this wasn't written clearly:  This was a response to your  
> second question, not a continuation of the bquote() suggestion.

It was clear enough ;). I need to learn to use bquote more often ....

Haris Skiadas
Department of Mathematics and Computer Science Hanover College

> Duncan Murdoch
> is the evaluation of er might not be
>> right.  Just because it is an argument to bar doesn't mean bar's  
>> frame or parent.frame() is the right place to evaluate it.
>> To check for errors, I'd introduce like-named variables at lots of  
>> levels, and then put them into the expression you were evaluating  
>> in such a way that you can tell which one was found.  For example,  
>> put
>> x <- "foo" into foo(), x <- "bar" into bar(), and x <- "global"  
>> into the global environment.  Then evaluate some expression that  
>> prints x and make sure you see the right one.
>> Duncan Murdoch

>>> ..expr <- eval(..txt, ..obj, parent.frame())
>>> ..expr <- eval(..expr, parent.frame())
>>> eval(..expr, ..obj)
>>> }
>>> bar <- function(parent, er, ...) {
>>> .fr=parent
>>> g <- substitute(er)
>>> foo(.fr, g)
>>> }
>>> > foo(5,.)
>>> [1] 5
>>> > bar(5,.)
>>> [1] 5
>>> mailing list PLEASE do read the posting guide and provide commented, minimal, self-contained, reproducible code. Received on Mon 24 Dec 2007 - 03:35:07 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Mon 24 Dec 2007 - 04:30:21 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.