Re: Multi-parameter type classes

[Fergus Henderson]

In ,
Simon L Peyton Jones <[EMAIL PROTECTED]> wrote:

 |5. In the signature of a class operation, every constraint must
 |   mention at least one type variable that is not a class type
 |   variable. Thus:
 ...
 |   > class C a where
 |   >op :: Eq a => (a,b) -> (a,b)
 |
 |   is not OK because the constraint (Eq a) mentions on the class type
 |   variable a, and no others.

What's the rationale for this rule?

 |   (GHC 3.02 enforces a more restrictive rule, but that's definitely
 |   wrong.)
 |   A yet more relaxed rule would allow the context of a class-op
 |   signature to mention only class type variables. I don't like that
 |   from an implementation point of view;

Could you be more specific?  What's the implementation difficulty?

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.

Re: Multi-parameter type classes

[Simon L Peyton Jones]

>  |5. In the signature of a class operation, every constraint must
>  |   mention at least one type variable that is not a class type
>  |   variable. Thus:
>  ...
>  |   > class C a where
>  |   >op :: Eq a => (a,b) -> (a,b)
>  |
>  |   is not OK because the constraint (Eq a) mentions on the class type
>  |   variable a, and no others.
> 
> What's the rationale for this rule?

It's hard to explain (which may well mean my head is on backwards).
In the 5 mins I have today here's what I added to the document


The reason it's awkward to implement is this. Supose you
are type checking the RHS of op in an instance declaration for C 
[c],
and suppose you have found that you need the constraint (C (S c)).
Should we reduce the constraint, in the hope being able to
"use" the Eq [c] we have available?  Or should we just
postpone this reduction for the top level of the class decl. 
Usually I make this decision based on whether the constraint mentions any
of the universally quantified type variables (b in this case),
which it doesn't.  Without this convenient test I have to either
to eager context reduction (which I don't want to do), or some sort
of search strategy.

Simon

Re: Multi-parameter type classes

[Andreas Rossberg]

Simon L Peyton Jones wrote:
> 
> GHC 3.02 supports multi-parameter type classes, but I have been
> guilty of not documenting precisely what that means.
> 
> I've now summarised the extensions, informally but I hope
> precisely, at
> 
> http://www.dcs.gla.ac.uk/multi-param.html

That does not seem to be the correct URL. I had better luck with:

http://www.dcs.gla.ac.uk/~simonpj/multi-param.html


- Andreas

Multi-parameter type classes

[Simon L Peyton Jones]

Folks,

GHC 3.02 supports multi-parameter type classes, but I have been
guilty of not documenting precisely what that means.

I've now summarised the extensions, informally but I hope
precisely, at

http://www.dcs.gla.ac.uk/multi-param.html

This includes some changes that aren't in 3.02, based on 
people's experiences with 3.02.

I'd be very glad of feedback.  In effect, this is a straw-man
proposal for Haskell 2.

Simon

Multi-parameter type classes in GHC 3.01

[Simon L Peyton Jones]

> PS. Could somebody inform me what is the current status of
> multi-parametric classes?


GHC 3.01 supports multi-parameter type classes
in more or less the form described in the last section of
"Type classes: an exploration of the design space"
(http://www.dcs.gla.ac.uk/~simonpj/multi.ps.gz)


We only mentioned this eliptically in the announcement, but
it should really have been a headline!  (The reason is that
we'd previously released 3.0 to friends, so we'd forgotten
that not everyone knew..)

It now seems very likely that Standard Haskell will support
multi-parameter type classes, and GHC 3.01 is our attempt
to gather feedback about whether we are moving towards
the right set of design choices.

The main limitation at the moment is

no overlapping instance declarations

There are ways to lift this restriction, but it's a conservative
first choice.

Please try it out, and let us know if you trip over
(a) bugs
(b) obscure error messages
(c) design restrictions that cramp your programming style

The URL is

http://www.dcs.gla.ac.uk/fp/software/ghc/

Simon