[Rd] Error condition in evaluating a promise

[Duncan Murdoch]

On 10/18/2006 1:17 PM, Roger D. Peng wrote:
> I've encountered a (I think) related problem when using promises to load 
> relatively large datasets.  For example something like
> 
> delayedAssign("x", getBigDataset())
> 
> runs into the same problem if you hit Ctrl-C while 'x' is being evaluated for 
> the first time.  Afterwards, there's no way to retrieve the dataset associated 
> with 'x'.

This is only true if the assignment was made in the global environment. 
  If that was executed within a function, or the assignment was made in 
any environment except .GlobalEnv, then you can use

substitute(x, env=whatever)

to recover the getBigDataset() function call.  It could then be 
re-evaluated.

Why is the global environment special?  For backwards compatibility, I'm 
told.

Duncan Murdoch

> 
> Active bindings work in this case, but the problem is that I usually only want 
> to load a large dataset once.
> 
> -roger
> 
> Robert Gentleman wrote:
>> Simon Urbanek wrote:
>>> Seth,
>>>
>>> thanks for the suggestions.
>>>
>>> On Oct 18, 2006, at 11:23 AM, Seth Falcon wrote:
>>>
>>>> Simon Urbanek <simon.urbanek at r-project.org> writes:
>>>>> thanks, but this is not what I want (the symbols in the environment
>>>>> are invisible outside) and it has nothing to do with the question I
>>>>> posed: as I was saying in the previous e-mail the point is to have
>>>>> exported variables in a namespace, but their value is known only
>>>>> after the namespace was attached (to be precise I'm talking about
>>>>> rJava here and many variables are valid only after the VM was
>>>>> initialized - using them before is an error).
>>>> We have a similar use case and here is one workaround:
>>>>
>>>> Define an environment in your name space and use it to store the
>>>> information that you get after VM-init.
>>>>
>>>> There are a number of ways to expose this:
>>>>
>>>> * Export the env and use vmEnv$foo
>>>>
>>>> * Provide accessor functions, getVmFooInfo()
>>>>
>>>> * Or you can take the accessor function approach a bit further to make
>>>>   things look like a regular variable by using active bindings.  I can
>>>>   give more details if you want.  We are using this in the BSgenome
>>>>   package in BioC.
>>>>
>>> I'm aware of all three solutions and I've tested all three of them  
>>> (there is in fact a fourth one I'm actually using, but I won't go  
>>> into detail on that one ;)). Active bindings are the closest you can  
>>> get, but then the value is retrieved each time which I would like to  
>>> avoid.
>>>
>>> The solution with promises is very elegant, because it guarantees  
>>> that on success the final value will be locked. It also makes sense  
>>> semantically, because the value is determined by code bound to the  
>>> variable and premature evaluation is an error - just perfect.
>>>
>>> Probably I should have been more clear in my original e-mail - the  
>>> question was not to find a work-around, I have plenty of them ;), the  
>>> question was whether the behavior of promises under error conditions  
>>> is desirable or not (see subject ;)). For the internal use of  
>>> promises it is irrelevant, because promises as function arguments are  
>>> discarded when an error condition arises. However, if used in the  
>>> "wild", the behavior as described would be IMHO more useful.
>>>
>>    Promises were never intended for use at the user level, and I don't 
>> think that they can easily be made useful at that level without exposing 
>> a lot of stuff that cannot easily be explained/made bullet proof.  As 
>> Brian said, you have not told us what you want, and I am pretty sure 
>> that there are good solutions available at the R level for most problems.
>>
>>    Although the discussion has not really started, things like dispatch 
>> in the S4 system are likely to make lazy evaluation a thing of the past 
>> since it is pretty hard to dispatch on class without knowing what the 
>> class is. That means, that as we move to more S4 methods/dispatch we 
>> will be doing more evaluation of arguments.
>>
>>     best wishes
>>       Robert
>>
>>
>>> Cheers,
>>> Simon
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>