[Haskell-cafe] Class invariants/laws

[Janis Voigtlaender]

Ryan Ingram wrote:
> These invariants are basically impossible to enforce by the compiler,
> but nonetheless certain classes have laws which are expected to hold,
> and I would not be surprised if (for example) GHC optimization RULES
> depended on them. 

I, in fact, would be surprised if there were such dependencies. (Not
that there might not be good reasons to want to rely on such laws for
some conceivable optimization, I just doubt that any implementation
actually does.)

Simon?

> For example, there's no way to enforce that the
> implementation of >>= is associative, but it's nonetheless stated in
> the description of Monad and code assumes it to be true.

Do you have an example of such code? Anyway, how can code "assume" >>=
to be associative? It would not make any difference for code whether or
not >>= is associative. What is, of course, possible is that programmers
assume >>= to be associative when doing refactorings of their code, such
as juggling with do-notation. As far as implementations are concerned, I
would conjecture that they all implement the single translation from
do-notation to >>=-notation specified in the report. No need for any
assumptions about associativity there. I might be wrong.

Ciao, Janis.

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