Re: [Haskell-cafe] class default method proposal
Simon Peyton-Jones wrote: Given instance C T where ..., for any method 'm' not defined by ...: for every class D of which C is a superclass where there is an instance for (D T) see if the instance gives a binding for 'm' If this search finds exactly one binding, use it, otherwise behave as now A better rule would be: If this search finds exactly one binding that is minimal in the partial ordering defined by the superclass hierarchy, use it, otherwise behave as now. Would that be much harder to implement? -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
Simon Peyton-Jones wrote: Concerning (b) here's a suggestion. As now, require that every instance requires an instance declaration. So, in the main example of http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data type T you'd write instance Monad T where return = ... (=) = ... instance Functor T instance Applicative T Another alternative is to allow multiple classes in an instance declaration: instance (Monad T, Functor T, Applicative T) where return = ... (=) = ... The advantage is that this makes it more clear where the instances come from, especially if a class has multiple sub classes with different defaults. It also eliminates tricky issues with importing. Of course this needs some (albeit very little) new syntax. I wrote a proposal a while ago, http://haskell.org/haskellwiki/Superclass_defaults Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
I had it pretty well worked out for single parameter type classes, but I couldn't see any nice extension to multiple parameters. On Dec 11, 2007 5:30 PM, Simon Peyton-Jones [EMAIL PROTECTED] wrote: | If it really would work ok we should get it fully specified and | implemented so we can fix the most obvious class hierarchy problems in a | nice backwards compatible way. Things are only supposed to be candidates | for Haskell' if they're already implemented. Getting it fully specified is the first thing. Personally I am not keen about a) coupling it to explicit import/export (independently-desirable though such a change might be) b) having instance declarations silently spring into existence Concerning (b) here's a suggestion. As now, require that every instance requires an instance declaration. So, in the main example of http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data type T you'd write instance Monad T where return = ... (=) = ... instance Functor T instance Applicative T The instance declaration for (Functor T) works just as usual (no explicit method, so use the default method) except for one thing: how the default method is found. The change is this: Given instance C T where ..., for any method 'm' not defined by ...: for every class D of which C is a superclass where there is an instance for (D T) see if the instance gives a binding for 'm' If this search finds exactly one binding, use it, otherwise behave as now This formulation reduces the problem to a more manageable one: a search for the default method. I'm not sure what is supposed to happen if the instance is for something more complicated (T a, say, or multi-parameter type class) but I bet you could work it out. All these instances would need to be in the same module: - you can't define Functor T without Monad T, because you want to pick up the monad-specific default method - you can't define Monad T without Functor T, because the latter is a superclass of the former It still sounds a bit complicated. Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
On Dec 11, 2007 3:19 PM, David Menendez [EMAIL PROTECTED] wrote: On Dec 11, 2007 9:20 AM, Duncan Coutts [EMAIL PROTECTED] wrote: So my suggestion is that we let classes declare default implementations of methods from super-classes. snip. Does this proposal have any unintended consequences? I'm not sure. Please discuss :-) It creates ambiguity if two classes declare defaults for a common superclass. My standard example involves Functor, Monad, and Comonad. Both Monad and Comonad could provide a default implementation for fmap. But let's say I have a type which is both a Monad and a Comonad: which default implementation gets used? Isn't a type which is both a Monad and a Comonad just Identity? (I'm actually not sure, I'm just conjecting) Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] class default method proposal
I'd just like to float an idea that's related to the Class Alias
proposal[1] but is perhaps somewhat simpler.
We all know that Functor should have been a superclass of Monad, and
indeed we now know that Applicative should be too. Making such a change
would break lots of things however so the change does not happen.
However in this case the Monad operations can be used to implement the
Functor and Applicative class methods. So it would be nice if we could
get them for free if the author did not choose to write the Functor and
Applicative instances.
So my suggestion is that we let classes declare default implementations
of methods from super-classes.
class Functor m = Monad m where
{- the ordinary bits -}
fmap f m= m = return . f
So if there already is a Functor instance for m then the default
implementation of fmap is not used.
Does this proposal have any unintended consequences? I'm not sure.
Please discuss :-)
Duncan
[1] http://repetae.net/recent/out/classalias.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
On Tue, Dec 11, 2007 at 02:20:52PM +, Duncan Coutts wrote:
I'd just like to float an idea that's related to the Class Alias
proposal[1] but is perhaps somewhat simpler.
We all know that Functor should have been a superclass of Monad, and
indeed we now know that Applicative should be too. Making such a change
would break lots of things however so the change does not happen.
However in this case the Monad operations can be used to implement the
Functor and Applicative class methods. So it would be nice if we could
get them for free if the author did not choose to write the Functor and
Applicative instances.
So my suggestion is that we let classes declare default implementations
of methods from super-classes.
class Functor m = Monad m where
{- the ordinary bits -}
fmap f m= m = return . f
So if there already is a Functor instance for m then the default
implementation of fmap is not used.
Does this proposal have any unintended consequences? I'm not sure.
Please discuss :-)
Duncan
[1] http://repetae.net/recent/out/classalias.html
This is almost exactly the
http://haskell.org/haskellwiki/Class_system_extension_proposal; that
page has some discussion of implementation issues.
Stefan
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
David Menendez wrote: On Dec 11, 2007 9:20 AM, Duncan Coutts [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: So my suggestion is that we let classes declare default implementations of methods from super-classes. snip. Does this proposal have any unintended consequences? I'm not sure. Please discuss :-) It creates ambiguity if two classes declare defaults for a common superclass. My standard example involves Functor, Monad, and Comonad. Both Monad and Comonad could provide a default implementation for fmap. But let's say I have a type which is both a Monad and a Comonad: which default implementation gets used? I'm disappointed to see this objection isn't listed on the wiki. Doesn't sound like a very big problem. That would just be a compile time error (More than one default for fmap possible for Foo, please reslve ambiguity). Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
On Dec 11, 2007 9:20 AM, Duncan Coutts [EMAIL PROTECTED] wrote: So my suggestion is that we let classes declare default implementations of methods from super-classes. snip. Does this proposal have any unintended consequences? I'm not sure. Please discuss :-) It creates ambiguity if two classes declare defaults for a common superclass. My standard example involves Functor, Monad, and Comonad. Both Monad and Comonad could provide a default implementation for fmap. But let's say I have a type which is both a Monad and a Comonad: which default implementation gets used? I'm disappointed to see this objection isn't listed on the wiki. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote: This is almost exactly the http://haskell.org/haskellwiki/Class_system_extension_proposal; that page has some discussion of implementation issues. Oh yes, so it is. Did this proposal get discussed on any mailing list? I'd like to see what people thought. Was there any conclusion about feasibility? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
Duncan Coutts wrote: On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote: This is almost exactly the http://haskell.org/haskellwiki/Class_system_extension_proposal; that page has some discussion of implementation issues. Oh yes, so it is. Did this proposal get discussed on any mailing list? I'd like to see what people thought. Was there any conclusion about feasibility? Ross proposed this on the libraries list in 2005: http://www.haskell.org//pipermail/libraries/2005-March/003494.html and I brought it up for Haskell': http://www.haskell.org//pipermail/haskell-prime/2006-April/001344.html see also this: http://www.haskell.org//pipermail/haskell-prime/2006-August/001582.html Unfortunately the Haskell' wiki doesn't have a good summary of the issues; it should. I'll add these links at least. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
On Tue, Dec 11, 2007 at 04:26:52PM +, Simon Marlow wrote: Duncan Coutts wrote: On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote: This is almost exactly the http://haskell.org/haskellwiki/Class_system_extension_proposal; that page has some discussion of implementation issues. Oh yes, so it is. Did this proposal get discussed on any mailing list? I'd like to see what people thought. Was there any conclusion about feasibility? Ross proposed this on the libraries list in 2005: http://www.haskell.org//pipermail/libraries/2005-March/003494.html and again in 2003: http://www.haskell.org/pipermail/haskell-cafe/2003-July/004654.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] class default method proposal
| If it really would work ok we should get it fully specified and | implemented so we can fix the most obvious class hierarchy problems in a | nice backwards compatible way. Things are only supposed to be candidates | for Haskell' if they're already implemented. Getting it fully specified is the first thing. Personally I am not keen about a) coupling it to explicit import/export (independently-desirable though such a change might be) b) having instance declarations silently spring into existence Concerning (b) here's a suggestion. As now, require that every instance requires an instance declaration. So, in the main example of http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data type T you'd write instance Monad T where return = ... (=) = ... instance Functor T instance Applicative T The instance declaration for (Functor T) works just as usual (no explicit method, so use the default method) except for one thing: how the default method is found. The change is this: Given instance C T where ..., for any method 'm' not defined by ...: for every class D of which C is a superclass where there is an instance for (D T) see if the instance gives a binding for 'm' If this search finds exactly one binding, use it, otherwise behave as now This formulation reduces the problem to a more manageable one: a search for the default method. I'm not sure what is supposed to happen if the instance is for something more complicated (T a, say, or multi-parameter type class) but I bet you could work it out. All these instances would need to be in the same module: - you can't define Functor T without Monad T, because you want to pick up the monad-specific default method - you can't define Monad T without Functor T, because the latter is a superclass of the former It still sounds a bit complicated. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
On Tue, 2007-12-11 at 16:38 +, Ross Paterson wrote: On Tue, Dec 11, 2007 at 04:26:52PM +, Simon Marlow wrote: Duncan Coutts wrote: On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote: This is almost exactly the http://haskell.org/haskellwiki/Class_system_extension_proposal; that page has some discussion of implementation issues. Oh yes, so it is. Did this proposal get discussed on any mailing list? I'd like to see what people thought. Was there any conclusion about feasibility? Ross proposed this on the libraries list in 2005: http://www.haskell.org//pipermail/libraries/2005-March/003494.html and again in 2003: http://www.haskell.org/pipermail/haskell-cafe/2003-July/004654.html Ross, you need to shout louder! :-) If it really would work ok we should get it fully specified and implemented so we can fix the most obvious class hierarchy problems in a nice backwards compatible way. Things are only supposed to be candidates for Haskell' if they're already implemented. So how about the objection that two sub classes could try and define conflicting defaults for a superclass method? David Menendez had the example of Monad and CoMonad defining Functor's fmap. Can that easily be rejected? I suppose it gives rise to duplicate instance declarations so it'd be an error in the same way that defining clashing instances in two different modules and importing both into a third module. Another error case would be: module A where data Foo module B where instance Functor Foo module C where instance Monad Foo module D import Bar import Baz Now we get slashing instances for Functor, since both Bar and Baz export Functor instances for Foo. Since the instance for Functor Foo was not visible in module C, so we get the default instance defined in C. So the one slightly surprising thing about this suggestion is that we get an instance defined or not depending on whether there is already an instance in scope. In the Functor, Applicative, Monad case I don't see that causing a problem in practise but is it worse more generally? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
Another suggestion, maybe completely off the wall, would be to do something with stand-alone deriving syntax? So instead of instance Functor T one might write deriving Functor for T ? This might make it more clear that default methods were being brought into play. With this syntax, it would seem appropriate to me that any case of overlap would produce an error (modulo, perhaps, some funny new ghc flag such as -fallow-overlapping-derivations). --s. instance Monad T On Dec 11, 2007, at 12:30 PM, Simon Peyton-Jones wrote: | If it really would work ok we should get it fully specified and | implemented so we can fix the most obvious class hierarchy problems in a | nice backwards compatible way. Things are only supposed to be candidates | for Haskell' if they're already implemented. Getting it fully specified is the first thing. Personally I am not keen about a) coupling it to explicit import/export (independently-desirable though such a change might be) b) having instance declarations silently spring into existence Concerning (b) here's a suggestion. As now, require that every instance requires an instance declaration. So, in the main example of http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data type T you'd write instance Monad T where return = ... (=) = ... instance Functor T instance Applicative T The instance declaration for (Functor T) works just as usual (no explicit method, so use the default method) except for one thing: how the default method is found. The change is this: Given instance C T where ..., for any method 'm' not defined by ...: for every class D of which C is a superclass where there is an instance for (D T) see if the instance gives a binding for 'm' If this search finds exactly one binding, use it, otherwise behave as now This formulation reduces the problem to a more manageable one: a search for the default method. I'm not sure what is supposed to happen if the instance is for something more complicated (T a, say, or multi-parameter type class) but I bet you could work it out. All these instances would need to be in the same module: - you can't define Functor T without Monad T, because you want to pick up the monad-specific default method - you can't define Monad T without Functor T, because the latter is a superclass of the former It still sounds a bit complicated. Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
What about something like instance Monad MyMonad where (=) = ... return = ... deriving ( Functor, Applicative ) That sounds like a friendlier version of SPJ's proposal, in that you no longer have to search for the default method, and every instance is actually manually declared. (I'm not sure if this is what Sterling meant by a stand-alone deriving syntax... it's not really stand-alone, and that's what I like about this idea, it restores locality.) David On Tue, Dec 11, 2007 at 12:59:06PM -0500, Sterling Clover wrote: Another suggestion, maybe completely off the wall, would be to do something with stand-alone deriving syntax? So instead of instance Functor T one might write deriving Functor for T ? This might make it more clear that default methods were being brought into play. With this syntax, it would seem appropriate to me that any case of overlap would produce an error (modulo, perhaps, some funny new ghc flag such as -fallow-overlapping-derivations). --s. instance Monad T On Dec 11, 2007, at 12:30 PM, Simon Peyton-Jones wrote: | If it really would work ok we should get it fully specified and | implemented so we can fix the most obvious class hierarchy problems in a | nice backwards compatible way. Things are only supposed to be candidates | for Haskell' if they're already implemented. Getting it fully specified is the first thing. Personally I am not keen about a) coupling it to explicit import/export (independently-desirable though such a change might be) b) having instance declarations silently spring into existence Concerning (b) here's a suggestion. As now, require that every instance requires an instance declaration. So, in the main example of http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data type T you'd write instance Monad T where return = ... (=) = ... instance Functor T instance Applicative T The instance declaration for (Functor T) works just as usual (no explicit method, so use the default method) except for one thing: how the default method is found. The change is this: Given instance C T where ..., for any method 'm' not defined by ...: for every class D of which C is a superclass where there is an instance for (D T) see if the instance gives a binding for 'm' If this search finds exactly one binding, use it, otherwise behave as now This formulation reduces the problem to a more manageable one: a search for the default method. I'm not sure what is supposed to happen if the instance is for something more complicated (T a, say, or multi-parameter type class) but I bet you could work it out. All these instances would need to be in the same module: - you can't define Functor T without Monad T, because you want to pick up the monad-specific default method - you can't define Monad T without Functor T, because the latter is a superclass of the former It still sounds a bit complicated. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
On Dec 11, 2007 1:29 PM, apfelmus [EMAIL PROTECTED] wrote: Without the automatic search, this is already possible class Functor f where fmap :: (a - b) - f a - f b class Functor m = Monad m where return :: a - m a (=) :: m a - (a - m b) - m b -- aka liftM fmapDefault :: Monad m = (a - b) - m a - m b fmapDefault f m = m = (return . f) instance Monad [] where return x = [x] (=)= flip concatMap instance Functor [] where fmap = fmapDefault fmap is already written for you, the instance declaration is only boilerplate. I first saw this in Data.Traversable . This is pretty much how I define Functor and Applicative instances for my monads. It is admittedly irritating to have to write out the boilerplate, but it doesn't seem irritating enough to require a language extension to eliminate. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
G'day all. Quoting David Menendez [EMAIL PROTECTED]: This is pretty much how I define Functor and Applicative instances for my monads. It is admittedly irritating to have to write out the boilerplate, but it doesn't seem irritating enough to require a language extension to eliminate. In the case of Functor and Applicative, that's true. Cases where it's likely to be more useful involve absurdly fine-grained class hierarchies, like the numeric prelude. Getting fanciful for a moment, and not claiming that this is a good structure: class Plus a b c | a b - c where (+) :: a - b - c class Minus a b c | a b - c where (-) :: a - b - c class Times a b c | a b - c where (*) :: a - b - c class Zero a where zero :: a class One a where one :: a class (Zero a, Plus a a a, Minus a a a) = Additive a where negate :: a - a negate a = zero - a a - b = a + negate b class (Mul a a a, One a) = Multiplicative a where (^) :: a - Integer - a class (Multiplicative a, Additive a) = Ring a where fromInteger :: Integer - a zero = fromInteger 0 one = fromInteger 1 class (Ring a, Ord a) = OrderedRing a where abs :: a - a abs x = x `max` negate x signum :: a - a -- etc class (OrderedRing a, Show a) = Num a You can imagine how unwieldy this would now get if you just wanted to declare an instance for Num a. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
