Haskell' - class aliases

[Claus Reinke]

>> Is this the most up-to-date description of the proposal?
>>         http://repetae.net/recent/out/classalias.html

what sounds nice about the class alias proposal is that it is pure
sugar, at least to the extent that type aliases are, but the design 
principle behind it seems to be that there should be a separate 
class for each method (as in Clean?), and that any compound 
classes should really just be class aliases (made to look like 
compound classes by the sugar), so that rearranging compound
classes comes down to defining more aliases for the same 
single-method base classes.

since this looks like class equivalence plus namespace handling,
i was wondering how far one could get without the proposed 
extension. this is slightly more difficult than the proposed translation
(which splits compound aliases into their components, so that the
alias class is always translated away), but it might still be of interest.

consider the 'class alias FooBar a = (Foo a,Bar a)' example
from the proposal page. we define FooBar and Foor/Bar in
separate modules and use that for namespace management.

- FooAndBar defines Foo and Bar, as well as a type X
    which is an instance of both

- FooBar defines FooBar, implicit derivations of FooBar 
    from Foo/Bar and vice-versa (the aliasing part), as well 
    as a type Y which is an instance of FooBar

    FooBar also arranges for Y to be an instance of Foo/Bar,
    and for X to be an instance of FooBar, via the implicit
    derivations, but controlled by instances of How

note the class 'How' and its instances, which ensure that 
any type class instance is either defined, or derived (in
a unique, specified way), but never both.

problems:

(1) instance method definitions by qualified names are
    not permitted, leading to the confusing 'foo = foo'
    (cf separate thread)
        
(2) overlapping instances, due to the derived instances;
    it seems this can be held in check by the use of 'How', 
    at the expense of some extra parameters/contexts/
    instances to control how each instance is defined/derived

example session:

    *FooBar> foo (X 1)
    False
    *FooBar> bar 0 (X 1)
    [X 1]
    *FooBar> foo (Y 1)
    True
    *FooBar> bar 0 (Y 1)
    [Y 1,Y 1]

    *FooBar> FooAndBar.foo (X 1)
    False
    *FooBar> FooAndBar.foo (Y 1)
    True
    *FooBar> FooAndBar.bar 0 (X 1)
    [X 1]
    *FooBar> FooAndBar.bar 0 (Y 1)
    [Y 1,Y 1]

    *FooBar> :t foo
    foo :: (FooBar a how) => a -> Bool
    *FooBar> :t FooAndBar.foo
    FooAndBar.foo :: (Foo a how) => a -> Bool
    *FooBar> :t bar
    bar :: (FooBar a how) => Int -> a -> [a]
    *FooBar> :t FooAndBar.bar
    FooAndBar.bar :: (Bar b how) => Int -> b -> [b]

i don't think i'd recommend this encoding style (it does not
quite fullfill the criterion of simplicity!-), but there you are:
class aliases encoded.

hth,
claus

ps. (for the TF vs FD fans: replacing FD class 'How' 
        with a TF doesn't seem to work; a bug?)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: FooAndBar.hs
Type: application/octet-stream
Size: 767 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20080425/c3555a23/FooAndBar.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FooBar.hs
Type: application/octet-stream
Size: 1381 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-prime/attachments/20080425/c3555a23/FooBar.obj