Polymorphic components, so far

[Iavor Diatchki]

Hello,

On 2/2/07, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
> Does your proposal cover only higher-rank types for *data constructors*?
Ticket 57 is about adding polymorphic components to datatypes which is
why my notes tried to focus on this issue.  Some of the issues are
related to the ticket that proposes allowing arbitrary functions to
have rank-2/N types and, of course, we should be consistent in our
design.

> | * Equality of schemes for labeled fields in different constructors.
> 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.)

I don't have a strong preference on this issue (although it would be
nice if the order of the predicates did not matter, as this would be a
first).  Stephanie was suggesting that perhaps a more semantics
comparison of schems might be useful, perhaps she has some examples?

> | * 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.

So far, most replys seemed to agree that this is not a big
restriction.  Could you give more details on how you think that should
work?   If we follow the current rules for pattern simplification,
then this feature might be a bit confusing.  Here is an example:

> data T = C (forall a. [a->a])
>
> f (C (f:fs)) = ...
>
> f x = case x of
>         C y -> case y of
>                  f : fs -> ...
>                  _ -> undefined

Notice that in the translation, when we 'case' on the 'y' the list
gets instantiated, so that 'f' is monomorphic.  There is nothing wrong
with that but I think that the may be more confusing than useful.

-Iavor