Polymorphic components, so far

[Simon Peyton-Jones]

Iavor

Does your proposal cover only higher-rank types for *data constructors*?  I don't think there is any problem with extending it to arbitrary functions, as our paper "Practical type inference for higher rank types" shows.  But the web page http://hackage.haskell.org/trac/haskell-prime/ticket/57 seems to cover only data constructors.

I hate the proposed restriction that a higher-rank function must be applied to all its polymorphic arguments. That's a hang-over from the earlier GHC rank-2 design, and I don't think it's necessary.  Again, the paper gives the details.

| * Notation for polymorphic types with explicit quantifiers.  The main
| issue is if we should allow some corner case notational issues, such
| as empty quantifier lists, and quantified variables that are not
| mentioned in the type.
|   - option 1: disallow these cases because they are likely to be
| accidental mistakes.

I lean to this too.

| * Equality of schemes for labeled fields in different constructors.
| My suggestion did not seem to be too controversial.  Stephanie is
| leaning towards a more semantic comparison of  schemes.  Indeed, just
| using alpha equivalence might be a bit too weak in some cases.
| Another, still fairly syntactic option, would be to pick a fixed order
| for the variables in quantifiers (e.g., alphabetic) for the purposes
| of comparison.

GHC uses equality modulo alpha conversion, but not modulo reordering of type variables or contexts.  This is easy to explain to programmers, and of course it's easy for the programmer to ensure.  Why would you want the more expressive semantic equality in practice?  I think this a solution seeking a problem.   Why complicate things?  (Same goes for the predicates in the context.  Let's insist they are the identical.)

| * Pattern matching on polymorphic fields.  This does not appear to be
| too controversial, although Atze  had some reservations about this
| design choice.

I removed this because I thought it was tricky to implement (given GHC's code structure).  But I needed something very similar for associated types, so now GHC's code structure makes it easy, and I'm planning to put it back in.

It's a small thing -- I have had one or two bug reports since removing it, but it's not a feature many will miss.  Still, it seems "natural" to allow it (e.g. disallowing it requires extra words in the language spec), which is why I think I'll add it.

Simon