Re: Defaults for superclass methods

[Cale Gibbard]

On 14/04/06, Dave Menendez <[EMAIL PROTECTED]> wrote:
> 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?

The simple solution is to make it an error, and force the programmer
to define an instance of Functor as soon as that happens. Most of the
problems seem to happen in mostly-linear hierarchies anyway.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: Defaults for superclass methods

[Dave Menendez]

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 <[EMAIL PROTECTED]> | "In this house, we obey the laws
  |of thermodynamics!"
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: Defaults for superclass methods

[Ashley Yakeley]

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/

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: Defaults for superclass methods

[John Meacham]

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⑈
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: Defaults for superclass methods

[Simon Marlow]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

Re: Defaults for superclass methods

[Ross Paterson]

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'?

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime