[Rd] Error condition in evaluating a promise

[Roger D. Peng]

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'.

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
>>
> 

-- 
Roger D. Peng  |  http://www.biostat.jhsph.edu/~rpeng/