Phil wrote:
> Both (>=) and (-) belong to classes defined in PreludeCore,
> and hence cannot be rebound. This was a deliberate decision,
> made in order to turn your point into a non-problem.
>
> Long live (n+k)! -- P
The Report tries to handle this by "always implicitly importing"
PreludeCore. This is not sufficient to prevent rebinding, e.g. if
somebody calls a formal parameter (>=).
There is a related story w.r.t. the Definition of Standard ML.
In its appendix, the SML report defines the meaning of
some so-called "derived forms" in form of rewrite rules (e.g. it
rewrites if-then-else into case-expressions and case-expressions into
function application). These rewrite rules also use predefined
identifiers (like true and false), which means that SML has exactly
the same problems as Haskell.
I took it for granted that the SML definition "meant" to refer to
predefined identifiers, and all the standard implementations agreed on
that. However, when I had an email-dispute with somebody who was
involved in designing the SML definition about some of the problems
relating to this, I was very surprised to find out that he was
willing to understand the definitions literally and leave it to the user
to modify the meaning of if-then-else by redefining true
if s/he chooses to do so.
I was even more surprised to hear from Dave Berry who works on
Harlequin's SML compiler that their prototype indeed implemented
these rules literally [well, almost: they did not get the "identifier
status" bit right, a problem that does not exist in Haskell];
I am not sure whether their final release will still contain this feature,
at least I discouraged them.
Moral: do not take anything for granted, you can end up with somebody's
implementation violating your hidden assumptions.
--
Stefan Kahrs
P.S.
I join Lennart's "Ban n+k pattern"-movement.
