Ben Rudiak-Gould wrote:
Brian Hulley wrote:
One motivation seems to be that in the absence of whole program
optimization, the strictness annotations on a function's type can
allow the compiler to avoid creating thunks at the call site for
cross-module calls whereas using seq in the function body itself
means that the thunk still has to be created at the call site
because the compiler can't possibly know that it's going to be
immediately evaluated by seq.
GHC solves this with the worker-wrapper transformation: the code for
the wrapper is exported as part of the module's interface and inlined
at external call sites. It handles seq, unboxing, and so on and calls
the worker via a private interface.
Not that I think strictness information in the type system is a bad
idea.
Sounds cool. I wonder if strictness annotations are ever really needed (eg
if the "perfect optimizer" were possible to construct)?
One problem I see with strictness annotations in functions is that there
could easily be an exponential growth in variants of a function (and callers
of that function...) to handle different strictness requirements (eg for map
with all of Clean's list types etc) leading to a bit of a minefield for the
humble programmer... :-)
Regards, Brian.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
