(I sent a similar message a few days ago which got lost somewhere)
We have tried to express the semantics of some Haskell constructs by giving
a translation into "Kernel" Haskell (Report section 1.2).
This leads to difficulties because free variables in the translations can
be captured by the context in which the construct is used.
We have tried to use the importation rules applying to Prelude and
PreludeCore to ensure the desired behaviour, but this is insufficient and
unclear. Specifically
1) Everything exported by PreludeCore is implicitly imported into every
module, and cannot be renamed or redefined at the top level. This
covers standard classes, including their member functions, and
types, including the operators used in the translation of n+k patterns,
which means that these always refer to member functions of standard
classes, except perhaps in inner scopes where names used in the translation
have been locally rebound. It is intended that the Prelude meanings of
locally rebound names should be used in the translation but there is
nothing to enforce this.
2) Things exported by Prelude and not by PreludeCore are implicitly
imported into every module unless Prelude is explicitly imported, when they
can be subject to renaming or hiding. Despite this, we want names used in
translations to refer to the Prelude entities even though these might not
be visible at that point of the program because they are not imported, or
renamed and the names reused, or locally redefined.
I think that we should try a different approach, forget about the importing
mechanism, and make a single statement defining the intended semantics.
Section 1.2 (The Haskell Kernel) is the place. I propose adding the
following.
The translations given, and the identities given for the semantics of
case expressions, are not macros. A simple replacement of the
right-hand-side for the left-hand-side with substitution of parameters does
not give the intended semantics. The reason for this is that the
translations make use of certain names defined in the standard prelude (see
section 5.4), and macro substitution could result in the capture of these
names by locally defined entities, or the use of a name in a context in
which it is not defined at all because the part of the prelude in which it
is defined has not been imported. The general rule is: the use of a name
defined in the standard prelude in a translation intended to show the
semantics of a construct always implies the definition in the standard
prelude.
Then, people can locally rebind as much as they want, but the constructs
defined by translation will be unaffected.
The syntax makes it clear that the + and - used in patterns are not the
same as the varops denoted by these symbols, so are unaffected by
rebinding. I suppose a note could be added pointing this out if absolutely
necessary.
--brian
