[Haskell-cafe] Optimizing unamb by determining the "state" of a thunk?

[Christopher Lane Hinson]

I'm sort of backtracking from your opinion that this hnf would need to be 
in IO.  Are you imagining something like?

data (NFData a) => OnceNFData n = OnceNFData { the_data :: a, is_normal_form :: (IORef Bool) }

I think GHC generally prevents parallel evaluation of the same unevaluated 
shared thunk[1].

What we'd like to avoid is duplicate verification that a thunk is hnf. 
Do we have evidence that this verification ever actually consumes a lot of 
resources?

I don't see any reason why it shouldn't be possible to fully force a and 
update the IORef from unsafePerformIO.  I see no need for any 
additional thread safety here.

There is a relevant proposal in the haskell prime wiki[2].

Unless I'm way off topic.

Friendly,
--Lane

[1] http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/multiproc.pdf
[2] http://hackage.haskell.org/trac/haskell-prime/ticket/106

On Mon, 20 Apr 2009, Peter Verswyvelen wrote:

> Yes indeed. 
> 
> On Mon, Apr 20, 2009 at 3:42 PM, Jake McArthur <jake.mcarthur at gmail.com> wrote:
>             Sure, so hnf would give us a non-determined result, but I don't think that makes unamb any less referentially transparent ? the same value is always returned, and always reduced at least to hnf.
> 
> 
> I think it is hnf that Peter was talking about needing to be in IO, not unamb.
> 
> - Jake
> 
> 
> 
>