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.mcart...@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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
