You're assuming some particular representation where there are
bits to steal. I don't like this at all. I think tying deepSeq
to some particular implementation techniques is a reall *BAD* idea.
Any function that is not defineable in (pure) Haskell should be viewed
with utmost suspicion. The seq function is one of these. At least
seq has simple denotational semantics, which can't be said for deepSeq.
I say, put deepSeq in a type class (which is what I've done when I need
it).
-- Lennart
Andy Gill wrote:
On Apr 10, 2006, at 2:25 AM, John Meacham wrote:
On Mon, Apr 10, 2006 at 10:10:18AM +0100, Simon Marlow wrote:
It's not *completely* straightforward to implement, at least in GHC, and
at least if you want to implement it in a modular way (i.e. without
touching lots of different parts of the system).
The obvious way to "add a bit to a closure" is to use the LSB of the
info pointer, which currently is always 0. However, that means masking
out this bit every time you want to get the info pointer of a closure,
which means lots of changes to the runtime. The price seems pretty
high.
An alternative is to have two info tables for every constructor, one
normal one and one "deepSeq'd", and the normal one probably needs to
point to the deepSeq'd version. This doesn't require masking out any
bits, but it does increase code size (one extra info table + entry code
for every constructor, except possibly those that don't contain any
pointer fields), and one extra field in a constructor's info table.
Plus associated cache pollution.
Yet another alternative is to store fully evaluated data in a segregated
part of the heap. The garbage collector could do this - indeed we
already do something similar, in that data that has no pointer fields is
kept separate. Checking the "deepSeq" bit on a closure is then more
complicated - but this has the advantage that only the GC and storage
manager are affected.
None of these solutions is as simple and self-contained as I'd like :-(
it is unlikely it will even be possible to implement in jhc without
radical changes to its internals. there is just no where to attach a bit
to, and even if there were, there is no generic way to evaluate
something to WHNF, or even a concept of WHNF in final grin. (grin code
can look inside unevaluated closures, hopefully making the thunk
non-updatable)
I do not understand.
- (A) I'm calling for a recursive descent function that does seq. I could
write it in Haskell, for any specific type. How is seq implemented jhs?
- (B) Once we have this recursive function, I'm advocating for an
optimization
which will make it cheap. Why can't we just steal a bit in the (GHC)
info table,
rather than mess with LSB of pointers, or have two info tables?
Yes, in grin this information would need to be used at compile time
but the resulting code would be considerably faster. A deepSeq is
a gift to the compiler from the programmer.
Andy Gill
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
