From simon.urbanek at r-project.org  Wed Oct 18 20:04:31 2006
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Wed, 18 Oct 2006 14:04:31 -0400
Subject: [Rd] Error condition in evaluating a promise
In-Reply-To: <4536618D.9070409@gmail.com>
References: <0359A469-1F7D-4CEF-A408-CCB185D5F90E@r-project.org>	<6phvemixy1u.fsf@gopher4.fhcrc.org>	<6phvemiuw3r.fsf@gopher4.fhcrc.org>	<9AE19AAE-9CAD-4697-82DC-07724445114C@r-project.org>	<m2d58psl5d.fsf@ziti.local>	<5EB2115D-9911-4268-85FA-9AB03F0D9009@r-project.org>
	<45365539.9050106@fhcrc.org> <4536618D.9070409@gmail.com>
Message-ID: <8332D09D-AAE2-4892-94DE-64E2AA4509EF@r-project.org>


On Oct 18, 2006, at 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'.
>
> Active bindings work in this case, but the problem is that I  
> usually only want to load a large dataset once.
>

I agree. There are basically a few options AFAICS:
1) document in delayedAssign that error conditions during evaluation  
will lead to unusable/unrecoverable state of the promise and add a  
note discouraging the use of promises in R code (as they were never  
meant for that)
2) reset PRSEEN on error in eval of the promise code (probably  
expensive as it would apply to every promise)
3) optionally add a flag to promises created by delayedAssign such  
that those can be distinguished and handled separately (e.g. don't  
set PRSEEN, or install an error handler before evaluation to reset  
PRSEEN). This would not affect the internal use of promises and thus  
would have no impact on speed. It would, however, make them more robust.
4) add a function that will reset a 'rogue' promise (e.g.  
recoverDelayed(sym, env)) which could be used in a custom error  
handler in the promise code. This is basically poor man's version of 3)

Personally I would vote for 3), but I can see the arguments for 1).

Cheers,
Simon




[Rd] Error condition in evaluating a promise
Simon Urbanek