Various language extensions (vote early, vote often!)

[haskell-request@cs.glasgow.ac.uk]

Date: 29 May 91  5:45
From: haskell-request@cs.glasgow.ac.uk
Sender: john peterson <peterson-john@cs.yale.edu>
To: haskell@cs.yale.edu
Subject: Various language extensions (vote early, vote often!)

Original-Via: uk.ac.nsf; Wed, 29 May 91 05:41:18 BST
Original-Sender: peterson-john@cs.yale.edu

Some opinions on recent suggestions for language changes:

1. Where/Let: the official proposal (to be posted tomorrow) looks
reasonable.  This cleans up a major problem and I agree with the
justifications we've already seen.

2. Monomorphism: I'll put this in another message

3. Type sigs: the proposal here is as follows.
     a) Place signatures before default definitions in class decls
     b) Disallow signature declarations in instances
     c) Disallow multiple signatures for the same variable
I'll agree with all three.  a) should make class declarations more
readable.  b) removes an unnecessary (since the instance context and
operator signature completely defime the type) and syntacticly odd
(the context is remote) signature declaration.  c) makes the language
simpler; multiple signatures for a variable are more likely the result
of a mistypes variable name anyway.

4. Abbreviations in export lists: allowing a module to name it's local
definitions without a full enumeration of all names is an obvious and
useful addition to the language here and presents no implementation
problems.

5. Sections: I'd like to see a concrete syntax here.  In principle,
though, it seems worthwhile to add them.

6. Bindings in list comprehensions: there is no reason not to do this.
I agree with Joe that the most useful semantics for pat = exp should be
pat <- [exp].  This is trivial to implement.

7. Extended names in interfaces: Joe's proposal seems reasonable but
since we're not yet implementing interface files I'll defer to the
opinion in Glasgow.  A much bigger issue will be the presentation of
non-standard information in interface files (strictness, inlining,
uncurrying, ...) but this should wait for Haskell 2.

The only big issue to resolve that I can see is the monomorphism
problem.  The issues above seem pretty non-controversial (except maybe
the interface files - could someone respond to Joe on this??)

   John