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 <[EMAIL PROTECTED]> 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@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
