For the reasons talked about in previous posts, I'd like to propose a
deepSeq
for Haskell'.
- It provides a mechanism to allow an effective, systematic
tracking down of
a class of space leaks.
- It provides a mechanism to simply stomp on a class of space leaks.
- It avoids the user having to explicitly declare instances for a
homebrew deepSeq
for every type in your program.
- It has a declarative feel; this expression is hyper strict.
- Is a specification of strictness.
- It will open up various optimization opportunities, avoiding
building thunks.
(I dont talk about this more, but I'm happy to elaborate)
- It can have an efficient implementation, or a simple (slow)
implementation.
(The fast implementation one can be used to stomp space leaks,
the slow one can help find the same leaks.)
What I would like to propose for Haskell' are four things:
(Essential) Add a deepSeq function into Haskell'
deepSeq :: a -> b -> b
- Don't really care if its in a class or not; would prefer not for
the reasons John Hughes talked about.
- This would deepSeq all its children for regular constructors.
- deepSeq would not indirect into IO or MVar.
- functions would be evaluated to (W?)HNF.
- IO, ST are functions under the hood.
(Easy) Add a $!! function, and a strict function
f $!! a = a `deepSeq` f a
strict a = a `deepSeq` a
(Nice) Add a !! notation, where we have ! in datatypes.
data StrictList a = Cons (!!a) (!!StrictList a) | Nil
(Perhaps) Add a way of making *all* the fields strict/hyperstrict.
data !!StrictList a = ..,
We could also do this for !
--------------
Implementation:
deepSeq (RAW_CONS
On Thu, Mar 30, 2006 at 02:12:29PM -0800, Andy Gill wrote:
- How easy is this to add to the compilers? It looks pretty simple to me,
jhc already has it by accident, it uses DrIFT for implementing its deriving methods which has had deepSeq deriving for a while. (though, it calls it 'rnf' for reduce to normal form)
and would provide huge bang-for-buck for Galois.
out of curiosity, do you use tools like DrIFT or TH to auto-generate DeepSeq instances for you?
- Any alternatives to the key concern; stomping on space leaks. (This proposal is orthogonal to the seq/Class discussion)
One thing, in order to deepSeq arbitrary types, it would mean heap locations need to be self-describing, which is not true in general for some haskell implementations. (the tag might have been unboxed away for instance, or you only have an opaque code pointer representation) requiring a typeclass DeepSeq a => would solve this problem as the "shape" of the type will be carried in the typeclass, either as a method(ghc) or a type parameter (in jhc) or discarded on implementations that don't need it. (yhc I am guessing?) So what I'd like to see is for the compiler to be able to auto-derive a DeepSeq instance so compilers are free to choose the best implementation method. incidentally, I'd like to see the same thing for Typeable. John -- John Meacham - ⑆repetae.net⑆john⑈
Andy Gill wrote:
- [various reasons for deepSeq]
You left out the one that most interests me: ensuring that there are no exceptions hiding inside a data structure.
deepSeq :: a -> b -> b
This ties demand for the (fully evaluated) normal form of an expression to demand for the WHNF of a different expression, which is a bit weird. I think it's cleaner for the primitive to be your "strict", which ties demand for the normal form of an expression to demand for the WHNF of the same expression. In fact I'd argue that "deepSeq" should not be provided at all (though of course it can be defined by the user). The analogy with seq is a bit misleading---deepSeq is a lot less symmetric than seq. The expressions (x `deepSeq` y `deepSeq` z) and (strict x `seq` strict y `seq` z) are equivalent, but only the latter makes it clear that z doesn't get fully evaluated. -- Ben
participants (3)
-
Andy Gill -
Ben Rudiak-Gould -
John Meacham