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

I join Lennart's "Ban n+k pattern"-movement.

Reply via email to