RE: Defaults for superclass methods
On 11 April 2006 11:08, Ross Paterson wrote:
On Tue, Apr 11, 2006 at 11:03:22AM +0100, Simon Marlow wrote:
This is a rather useful extension, and as far as I can tell it doesn't have a ticket yet:
http://www.haskell.org//pipermail/libraries/2005-March/003494.html
should I create a ticket? Is there any reason it might be hard to implement?
There are a range of proposals, but none of them are implemented. Wouldn't that rule them out for Haskell'?
If it's not clear which is the right way to go, then yes I guess that does rule it out. Could you summarise the proposals? If there was a clear winner, and it was easy enough to implement, perhaps we can knock up a prototype in time. The reason being I just hit a case where this would be useful, while trying to find a nice way to express extensible exceptions. Cheers, Simon
On Tue, Apr 11, 2006 at 11:35:09AM +0100, Simon Marlow wrote:
On 11 April 2006 11:08, Ross Paterson wrote:
On Tue, Apr 11, 2006 at 11:03:22AM +0100, Simon Marlow wrote:
This is a rather useful extension, and as far as I can tell it doesn't have a ticket yet:
http://www.haskell.org//pipermail/libraries/2005-March/003494.html
should I create a ticket? Is there any reason it might be hard to implement?
There are a range of proposals, but none of them are implemented. Wouldn't that rule them out for Haskell'?
If it's not clear which is the right way to go, then yes I guess that does rule it out. Could you summarise the proposals? If there was a clear winner, and it was easy enough to implement, perhaps we can knock up a prototype in time.
As I recall, this was brought up a few times during the class alias discussion and there were good technical reasons why it would be tricky to define a sane semantics for it. as in, it's harder than it first looks. John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham writes:
On Tue, Apr 11, 2006 at 11:35:09AM +0100, Simon Marlow wrote:
On 11 April 2006 11:08, Ross Paterson wrote:
On Tue, Apr 11, 2006 at 11:03:22AM +0100, Simon Marlow wrote:
This is a rather useful extension, and as far as I can tell it doesn't have a ticket yet:
http://www.haskell.org//pipermail/libraries/2005-March/003494.html
should I create a ticket? Is there any reason it might be hard to implement?
There are a range of proposals, but none of them are implemented. Wouldn't that rule them out for Haskell'?
If it's not clear which is the right way to go, then yes I guess that does rule it out. Could you summarise the proposals? If there was a clear winner, and it was easy enough to implement, perhaps we can knock up a prototype in time.
As I recall, this was brought up a few times during the class alias discussion and there were good technical reasons why it would be tricky to define a sane semantics for it. as in, it's harder than it first looks.
The tricky part is dealing with multiple subclasses.
For example,
class Functor f where
fmap :: (a -> b) -> f a -> f b
class Functor f => Monad f where
...
fmap = liftM
class Functor f => Comonad f where
...
fmap = liftW
newtype Id a = Id a
instance Functor Id
instance Monad Id
instance Comonad Id
Which default gets used for fmap?
--
David Menendez
Simon Marlow wrote:
If it's not clear which is the right way to go, then yes I guess that does rule it out. Could you summarise the proposals? If there was a clear winner, and it was easy enough to implement, perhaps we can knock up a prototype in time.
The reason being I just hit a case where this would be useful, while trying to find a nice way to express extensible exceptions.
If we're going to do this, we should make Functor a superclass of Monad. This is a well-known and annoying wart in the standard libraries that has not been fixed only because there's no superclass default mechanism. -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/
participants (4)
-
Ashley Yakeley -
Dave Menendez -
John Meacham -
Simon Marlow