| > Yes, I think this should be fixed, and perhaps it could be done in a | > backward compatible way? If classes were allowed to declare default | > methods for superclasses, then you could have | > | > class Functor f where fmap :: ... | > class Functor m => Monad m where | > ...the usual stuff... | > fmap = liftM | > | > Then declaring | > | > instance Monad T where ... | > | > for some T, would implicitly introduce an instance Functor T, if it is | > not defined explicitly... It seems overkill to have a whole new language feature to deal with one library issue. It would take a bit of implementing too, and it's not clear to me what the specification is. For example, what if Functor T *is* defined explicitly, but in a later module? The idea comes up very occasionally, but I wouldn't say it's been a hot issue. Simon
Why not just have the new definition with a different import path, so that legacy code continues to do: import Control.Monad And new code could do: import Control.Category.Monad (or something) And we could take this opportunity to incorporate premonads... class Functor f -- defines fmap class Functor p => Premonad p -- defines return class Premonad m = Monad m -- defines bind Keean. Simon Peyton-Jones wrote:
| > Yes, I think this should be fixed, and perhaps it could be done in a | > backward compatible way? If classes were allowed to declare default | > methods for superclasses, then you could have | > | > class Functor f where fmap :: ... | > class Functor m => Monad m where | > ...the usual stuff... | > fmap = liftM | > | > Then declaring | > | > instance Monad T where ... | > | > for some T, would implicitly introduce an instance Functor T, if it is | > not defined explicitly...
It seems overkill to have a whole new language feature to deal with one library issue. It would take a bit of implementing too, and it's not clear to me what the specification is. For example, what if Functor T *is* defined explicitly, but in a later module?
The idea comes up very occasionally, but I wouldn't say it's been a hot issue.
Simon
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On Thu, Mar 24, 2005 at 08:40:14AM -0000, Simon Peyton-Jones wrote:
[Thomas Hallgren wrote:] | > Yes, I think this should be fixed, and perhaps it could be done in a | > backward compatible way? If classes were allowed to declare default | > methods for superclasses, then you could have | > | > class Functor f where fmap :: ... | > class Functor m => Monad m where | > ...the usual stuff... | > fmap = liftM | > | > Then declaring | > | > instance Monad T where ... | > | > for some T, would implicitly introduce an instance Functor T, if it is | > not defined explicitly...
It seems overkill to have a whole new language feature to deal with one library issue. It would take a bit of implementing too, and it's not clear to me what the specification is. For example, what if Functor T *is* defined explicitly, but in a later module?
It's not just here -- this would make lots of fairly fine-grained class hierarchies a lot less painful. But I agree that there's a cross-module problem. It may be necessary to require that instances of classes linked in this way be defined in the same module, but that wouldn't be backwards compatible either.
Simon Peyton-Jones wrote:
| > | > class Functor f where fmap :: ... | > class Functor m => Monad m where | > ...the usual stuff... | > fmap = liftM | >
It seems overkill to have a whole new language feature to deal with one library issue.
Perhaps it is...
For example, what if Functor T *is* defined explicitly, but in a later module?
I guess it would be the same as what happens now if you accidentally declare the same instance in different modules, i.e., the system would complain about overlapping instances. -- Thomas H
participants (4)
-
Keean Schupke -
Ross Paterson -
Simon Peyton-Jones -
Thomas Hallgren