X-Comment1: #############################################################
X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs #
X-Comment3: # If this address does not work please ask your mail #
X-Comment4: # administrator to update your NRS & mailer tables. #
X-Comment5: #############################################################
This message is meant to summarise the non-trivial proposed changes
to the Haskell report. I'll omit typos, infelicitous wording,
and bugs in the Prelude. All of these are discussed in detail in earlier
messages from me (I'm afraid). I hope to have all the decisions taken by
the end of the week. Then your Haskell mail should return to a more
normal level.
Simon
Superclasses
~~~~~~~~~~~~
Proposed: If a type T is declared to be an instance of a class C then T must
also be explicitly declared to be an instance of C's superclasses.
Type synonyms (in interfaces)
~~~~~~~~~~~~~
Proposed: synomyms may (but need not) appear in interface type signatures;
but if they do then the closure rule means that the synonym must be in scope.
PreludeCore
~~~~~~~~~~~
I propose to change the first sentence of 5.4.1 (page 49) to
"The PreludeCore module contains certain of the algebraic data
types, type synonyms, classes and instance declarations specified
by the standard prelude."
and after the second sentence, add
"PreludeCore thereby ensures consistent naming across all Haskell
programs for the entities it exports."
Type synonyms (in import statements)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proposed: allow only the T(..) form and NOT the T form, rather than the
other way round, as at present. This is just a syntax change, but it
enhances consistency.
Hiding
~~~~~~
Proposal: in hiding lists allow only the forms
var
T(..) -- Types
C(..) -- Classes
Renaming in interfaces
~~~~~~~~~~~~~~~~~~~~~~
This is Lennart's question, to which I replied yesterday (the Subject
field was "Need clarification..."). I am not sure how much to add
to the report about this.
Syntax changes
~~~~~~~~~~~~~~
THESE ARE UP TO PAUL HUDAK TO SETTLE; I summarise my understanding here.
a) a collection of precedence issues, especially affecting
- parenthesisation needed for lambda abstractions
- unary minus
b) lexical syntax of parenthesised ops. Currently you are allowed
( + 1 ), but not ( + ), which seems odd. You have to write
(+) with no spaces, cos it's one token.
c) a suggestion about the syntax of types from Kent.
d) disallow overgeneral p+k patterns like (C a b) + k or n + k + k'
Prelude changes
~~~~~~~~~~~~~~~
THESE ARE UP TO JOE FASEL TO SETTLE
a) move error to PreludeBuiltIn
