[Rd] Error condition in evaluating a promise

[Robert Gentleman]

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
> 

-- 
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
rgentlem at fhcrc.org