| From | Sent On | Attachments |
|---|---|---|
| John Meacham | Oct 12, 2005 7:41 pm | |
| Philippa Cowderoy | Oct 12, 2005 7:55 pm | |
| John Meacham | Oct 12, 2005 8:16 pm | |
| Wolfgang Jeltsch | Oct 13, 2005 5:48 am | |
| John Meacham | Oct 13, 2005 6:03 am | |
| Malcolm Wallace | Oct 13, 2005 6:15 am | |
| Andres Loeh | Oct 13, 2005 6:23 am | |
| Malcolm Wallace | Oct 13, 2005 6:29 am | |
| John Meacham | Oct 13, 2005 6:37 am | |
| John Meacham | Oct 13, 2005 6:39 am | |
| Simon Peyton-Jones | Oct 13, 2005 7:02 am | |
| Benjamin Franksen | Oct 13, 2005 7:26 am | |
| Benjamin Franksen | Oct 13, 2005 7:33 am | |
| S.M.Kahrs | Oct 13, 2005 7:37 am | |
| John Meacham | Oct 13, 2005 8:32 am | |
| Simon Peyton-Jones | Oct 13, 2005 9:23 am | |
| Udo Stenzel | Oct 13, 2005 9:46 am | |
| Jan-Willem Maessen | Oct 13, 2005 9:58 am | |
| Paul Govereau | Oct 13, 2005 1:21 pm | |
| Jacques Carette | Oct 13, 2005 1:52 pm | |
| John Meacham | Oct 13, 2005 4:45 pm | |
| John Meacham | Oct 13, 2005 6:13 pm | |
| John Meacham | Oct 13, 2005 6:21 pm | |
| David Menendez | Oct 13, 2005 6:49 pm | |
| John Meacham | Oct 13, 2005 8:33 pm | |
| aj...@spamcop.net | Oct 13, 2005 11:25 pm | |
| Ashley Yakeley | Oct 14, 2005 6:20 am | |
| Ashley Yakeley | Oct 14, 2005 6:31 am | |
| Wolfgang Jeltsch | Oct 14, 2005 9:46 am | |
| Wolfgang Jeltsch | Oct 14, 2005 11:44 am | |
| Wolfgang Jeltsch | Oct 14, 2005 11:47 am | |
| Remi Turk | Oct 14, 2005 2:05 pm | |
| Udo Stenzel | Oct 15, 2005 6:15 am | |
| Ross Paterson | Oct 27, 2005 6:58 am | |
| Wolfgang Jeltsch | Oct 28, 2005 7:05 am |
| Subject: | [Haskell] PROPOSAL: class aliases | |
|---|---|---|
| From: | John Meacham (jo...@repetae.net) | |
| Date: | Oct 13, 2005 6:37:27 am | |
| List: | org.haskell.haskell | |
On Thu, Oct 13, 2005 at 12:46:21PM +0200, Andres Loeh wrote:
One thought: how will class aliases interact with type inference? e.g. if a declaration contains only a call to 'foo', should we infer the constraint Foo a, or FooBar a? Can there ever be a situation where choosing the more specific dictionary could leave us without a 'bar' method at some later point in the computation? (cf. up-casting and down-casting in OO languages).
If I declare a function
baz :: Bar a => ...
and then pass it a value which actually has a FooBar dictionary rather than just a Bar, will the implementation be able to find the right offset in the dictionary for the 'bar' method? How? (I know jhc eliminates dictionaries at compile-time, but other implementations do not.)
The way I understand the proposal, there are no FooBar dictionaries ever. John said that this can be translated by a source-to-source translation, so internally, a FooBar dictionary *is* a Foo and a Bar dictionary.
This is correct. perhaps 'class synonym' might be a better name? FooBar a and (Foo a,Bar a) are actually equivalent as if it were replaced via a textual macro substitution. the only place they are treated differently is in instance heads as declaring an instance for an alias will declare instances for all of its components.
How much static checking can be done before desugaring the code? Will it be possible to give sensible error messages, or will those mention the "internal" classes that the alias is supposed to hide?
A simple implementation would mention all the 'internal' classes. but ghc already knows to replace [Char] with String, it could do something similar looking for when a bunch of constraints can be simplified into a shorter alias and printing that.
It also might be useful to have a pragma for the Haskell 98 names saying error messages should always be in terms of them when possible in haskell 98 mode so people learning from haskell 98 books arn't confused.
perhaps something looking at the current names in scope could also be done, like if you only have the aliased names in scope, print errors in terms of those rather than the internal ones.
How much this will be an issue in practice we will have to see. we might have to experiment some to find the best method for producing error messages.
John
-- John Meacham - ?repetae.net?john?





