[Haskell-cafe] Class invariants/laws

Janis Voigtlaender voigt at tcs.inf.tu-dresden.de
Fri Oct 19 04:01:13 EDT 2007


Ryan Ingram wrote:
> On 10/18/07, Janis Voigtlaender <voigt at tcs.inf.tu-dresden.de> wrote:
> 
>>Yes, but that's a problem of the Arrow library writer, not of GHC. The
>>compiler will never check a RULE.
> 
> 
> I'm going to disagree a bit here; it's not the problem of the Arrow
> library writer at all, it's the problem of the implementor of the
> faulty arrow (me, in this case). 

Yes, it's an issue between you and the Arrow library writer, not between
you and GHC.

>>I think what Simon was asserting is that none of the internal logic of
>>GHC assumes any laws to hold for any type classes.
> 
> 
> If that's the case, it doesn't address my original point at all, which
> was talking about the applicability of class laws to optimization
> RULES. 

Your original point was that GHC optimization RULES might depend on
class laws. That's obviously true, since anyone can write RULES in
source code. What I find reasserting about Simon's statement is that no
RULES (or other logic) that happen outside the control of the programmer
will depend on class laws being true. Note that GHC internally generates
RULES for some optimization tasks, without the compiler user having the
least inkling. It could easily have been the case that so it also
introduces an associativity law for >>= as given in the H98 report. Only
then I would see how code depends on that law actually being true.

Ciao, Janis.

-- 
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:voigt at tcs.inf.tu-dresden.de



More information about the Haskell-Cafe mailing list