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

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/multip... [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 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