Re: n+k patterns, etc.
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. This sounds reasonable to me. -Paul
Re: n+k patterns, etc.
(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
Re: n+k patterns, etc.
|What if (the appropriate parts of) the standard prelude is | explicitly *not* imported: | | import Prelude () | or | import Prelude hiding(map) | | (see section 5.4.3). | |Are then the hidden parts of the standard prelude still available via | n+k patterns, list comprehensions etc.? (Via some unseen and unhidable | intermediary module.) Or are constructs that use hidden parts of the | standard prelude (according to their translations given in the report) | not available? Yes. No. Respectively. The Report is obviously not clear enough on this point. The wording given for translations (eg list comprehensions) that "map" refers to the Prelude "map" is meant to indicate that it refers to the Prelude "map" whether or not the latter is explicitly in scope. That's the consistent story for all special syntax, to answer the latter part of your message. Simon
Re: n+k patterns, etc.
Some more questions concerning some constructs in Haskell: What if (the appropriate parts of) the standard prelude is explicitly *not* imported: import Prelude () or import Prelude hiding(map) (see section 5.4.3). Are then the hidden parts of the standard prelude still available via n+k patterns, list comprehensions etc.? (Via some unseen and unhidable intermediary module.) Or are constructs that use hidden parts of the standard prelude (according to their translations given in the report) not available? By the way, what about other special syntax constructs, like [...] for lists and (...,...,...) for tuples. Are these still available even if the standard prelude is not imported? Apparently lists and tuples cannot be selectively hidden, but the entire standard prelude can be hidden. Or, to rephrase the question, are such special syntax constructs reexported by the unseen and unhidable intermediary module mentioned in the previous paragraph? If so, then I think that the unhidable intermediary module for special syntax constructs should be made explicit (but, of course, still not codable in Haskell itself, due to the special syntax). Asking strange questions /kent k P.S. (Apropos Lennarts quiz) I think that the function names in "funlhs"es (in each let/where) should not be allowed to be rebound by some pattern whithin one of the "funlhs"es. I.e. id id = id should not be a definition of the identity function (while still allowing the definition id = \id.id). This would just naturally extend the "linearity restriction" in section 4.4.2, which disallows e.g. f x x = ... and f = \x x->... but allows f = \x->\x->... . (I don't dare go as far as proposing to ban "shadowing" completely.) /kn
