Haskell' - class aliases

[John Meacham]

On Fri, May 02, 2008 at 11:24:11AM +0100, Simon Peyton-Jones wrote:
> | The more I think about it, I think 'superclass' is just the wrong
> | terminology for dealing with class aliases. Superclass implies a strict
> | partial order on classes, which just isn't the case for class aliases,
> | for instance
> |
> | > class alias Foo a => Foo a = Bar a where ...
> 
> Crumbs!  I have no idea what that means!  Did you really mean to repeat "Foo"?  According to your expansion in type signatures
>         f :: (Foo a) => ...
> expands to
>         f :: (Foo a, Bar a) => ...
> which presumably expands again.  I'm totally lost here

Yes I did, because I wanted to make the differences between class alias
contexts and superclasses very clear, the above context is valid, if
vacuous. the expansion goes as follows .

1. Foo a --> reduce(Foo a,Bar a)
        -- Foo a expanded
2. reduce(Foo a,Bar a) --> (Foo a,Bar a)  
        -- no entailment reduction possible, reduction is unchanged from H98
3. (Foo a,Bar a) -> reduce(Foo a,Bar a,Bar a)
        -- Foo a expanded
4. reduce(Foo a, Bar a, Bar a) -> (Foo a, Bar a) 
        -- reductino removes duplicates

5. we notice we are the same as in step #2. fixed point reached, we stop
expansion.

6. we remove all class aliases from result:

(Foo a, Bar a) -> Bar a

7. 'Bar a' is our final result.


informal proof of termination:

each step adds a new class or class alias to the context, there are a
finite number of classes or class aliases, therefore we must eventually
reach a fixed point.

> Have a look at my last message, which gives a variant of your
> desugaring that IMHO greatly clarifies the meaning of (what I
> understand by) aliases.

I think the difference in what we mean is that I intend class aliases to
be a true bijection in all contexts (isomorphism?) between a single
alias and a set of classes. This is opposed to superclasses which are a
one directional implication.

One of my main motivations is being able to mix unchanged H98 and H'
code (with different numerical hierarchies, and both calling each other)
without modifications or prefered treatment for either. this means
instances for H' must silently and transparently create instances for
H98 classes and vice versa, moreso, type signatures should be
compatible.

As in, the H' specification should be able to make absolutely no
reference to H98 and vice versa, yet class aliases allow one to write a
compiler that seamlessly allows mixing code from the two without
compromising the design of either.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈