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@tcs.inf.tu-dresden.de