Phil suggests that we add
newtype T a_1 ... a_k = C t_1 ... t_n
and use that to construct non-lifted ADTs. While this works
well, I'd prefer to have strictness annotations on construtors
instead. Haskell has very few means for making programs
more efficient when you really need it, and strict constructors
would be one way.
My example with Complex from FPCA also shows that having strict
constructors can make an enormous difference in performance.
And in this case non-lifted products wouldn't have made it any
better.
The big disadvantage with strict polymorhic constructors is that
they are not lambda-definable and would thus be a step away from
the Haskell policy of having everything lambda definable.
(Having both strict polymorhic constructors and non-lifted products
would be a disaster from an implementation point of view since
it requires parallel evaluation to be implemented correctly.)
> A secondary reason was that we were afraid of the potential cost
> of unlifted products. We now have the tools in place to measure
> such costs. Simon, Lennart, Paul, would this be difficult to do?
I'd say we've had those tools a long time. :-)
It would be very easy to measure, but I'm not quite sure what
you want to measure. Just unlifted tuples? In a well-written
program this would make little difference since it's bad software
engineering to use tuples, so I wouldn't expect big programs to
use them a lot (you should define a new type instead of using a
tuple since that gives better documentation and types).
Or should we try and unlift all types with a single constructor?
I still favour strict (polymorhic) constructors.
-- Lennart
