[project @ 2001-08-02 16:05:06 by simonmar]
Fix something that looks wrong in an attempt to get HEAD back on the
rails again, whilst trying to get the award for the highest
size-of-commit-message-to-number-of-lines-actually-changed ratio.
The problem is this: a constructor defined as
data T = A !Int
will cause a DataCon wrapper to be generated like this:
A = \x -> case x of x' { DEFAULT -> $wA x' }
but the strictness on $wA says that it is strict in its first field.
This is where the story gets a little hazy, but it seems that the
compiler (5.00.2) happily removes the extra case thinking that x is
going to get evaluated anyway, leaving us with
A = \x -> $wA x
and the argument to A ends up not being evaluated at all. Certain
other parts of the compiler make use of the evaluatedness of fields in
order to remove unnecessary cases, with the end result that we end up
trying to dataToTag# an unevaluated thing, and certain derived Eq
instances can give wrong results. Phew.
Now, here's the bit I *don't* understand: I can only see the bug with
5.00.2, and only when the data type has more than one constructor:
data T = A !Int | B
nevertheless, the HEAD compiler when bootstrapped displays symptoms of
a broken Eq instance, so I'm trying this fix to see if it helps.
The Attempted Fix: give the DataConId a fully-lazy strictness
signature.