Error condition in evaluating a promise

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.

Cheers,
Simon