>If (as a human reader of a programme) I see > >do a <- thing1 > <expression> > >and I notice (perhaps after some modifications) that a is >not present in <expression>, then I /really/ don't want a >change to > >do thing1 > <expression> > >to change the meaning of the programme.
That's understandable, just like it's understandable that a programmer does not want to read a program that redefines id or const or map to something with a completely different meaning. But is that any reason for the language standard to *disallow* redefinition of id or const or map? And if the answer is yes, where does this proscriptive zeal stop? Should the language standard, eg, disallow functions whose name ends in 'M' but do not have monads in their signature? No: the individual programmer should be free to decide to override conventions if doing that is expedient. After all, there is no danger that what James wants to do will become common or widespread; it's just an expediency to deal with a rare situation. The bottom line is a social one: language communities compete fiercely for programmers. There is no shortage of languages with open-sourced implementations in which James could have written his program. (Er, actually James is embedding a DSL in Haskell, which brings many programmers to Haskell.) If we want Haskell to grow, we must make it as easy as possible for programmers to solve their problems in Haskell. Of course there are some things that are essential to Haskell that we should not compromise on. Those who describe a >> b = a >>= \_ -> b as a law might maintain that it is one of those essential things. Well, to them I ask, are id x = x and const x y = y laws, too? How about fix f = f (fix f)? swap (a,b) = (b,a)? mirror (Right a) = Left a mirror (Left a) = Right a? etc, etc. _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell