">>" and "do" notation

[Richard Uhtenwoldt]

>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.