it would also be possible to require the compiler 'memoize' all top
level bindings on their type parameter. then the problem goes away, but
at the cost of hiding some machinery under the hood. however the type
analysis pass mentioned above would often be able to discard of this
'under the hood' memoization and.
We discussed this idea when Haskell was first designed. The trouble is,
there's an awful interaction with space leaks.
Imagine you have a binding
let x = ...e1... in ...e2...
where e1 contains pointers to some large structure, and then somewhere in e2
you need to drop those pointers. You write x `seq` ... at the place where you
want to drop the pointers, right? (Assuming the pointers are no longer
referred to from x's value). Wrong! If x is overloaded, then you've only
forced the evaluation of *one instance* of x, and e1, together with the
structures it points to, have to be retained in case you ever evaluate a
*different* instance of x in the future! Memooising x on its type makes no
difference to this: you have to retain e1 until every possible instance of
x has been evaluated. If there's a fixed finite number of possibilities
then this might be possible, if awkward ((x::Integer)`seq` (x::Float)`seq`...),
but if there are infinitely many possible instances then you're screwed.
So if it is to be *possible* to fix space leaks, then memoisation is not
a good alternative to shared bindings.
John
_______________________________________________
Haskell-prime mailing list
[email protected]
http://haskell.org/mailman/listinfo/haskell-prime
