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 puresugar, 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 Hownote 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, clausps. (for the TF vs FD fans: replacing FD class 'How' with a TF doesn't seem to work; a bug?)
FooAndBar.hs
Description: Binary data
FooBar.hs
Description: Binary data
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
