Re: [Haskell] The FunctorM library
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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] The FunctorM library
| 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
Re: [Haskell] The FunctorM library
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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The FunctorM library
On Thu, Mar 24, 2005 at 08:40:14AM -, 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. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] The FunctorM library
On Wed, 23 Mar 2005 19:14:41 -0800, Thomas Hallgren
[EMAIL PROTECTED] wrote:
Iavor Diatchki wrote:
Just to avoid confusion I think the suggestions were:
class Functor f = Monad f where ...
class Functor f = FunctorM f where ...
I know the first one differs from the Haskell report, but perhaps this
is a flaw in the library design that should be fixed.
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...
--
Thomas H
I agree, and think that's a great idea for solving that problem.
Does anyone see any possible difficulties with it?
I think that perhaps specifying the entire instance might make more sense, eg:
class Functor m = Monad m where
{- ... usual stuff ... -}
instance Functor m where
fmap = liftM
Having such a thing seems quite useful. As long as it doesn't break
the world, I'd personally like to have this feature.
One issue might be which default instance gets chosen when two classes
both provide default instances for a given class. Perhaps in this
case, we can just force the user to provide an instance, or produce a
compile-time warning and select one automatically in some canonical
fashion.
What do the Simons think?
- Cale
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The FunctorM library
On Wed, Mar 23, 2005 at 11:29:51PM -0500, Cale Gibbard wrote:
I agree, and think that's a great idea for solving that problem.
Does anyone see any possible difficulties with it?
I think that perhaps specifying the entire instance might make more sense, eg:
class Functor m = Monad m where
{- ... usual stuff ... -}
instance Functor m where
fmap = liftM
Having such a thing seems quite useful. As long as it doesn't break
the world, I'd personally like to have this feature.
One issue might be which default instance gets chosen when two classes
both provide default instances for a given class. Perhaps in this
case, we can just force the user to provide an instance, or produce a
compile-time warning and select one automatically in some canonical
fashion.
What do the Simons think?
This was brought up before, a problem is that an 'import' can silently
change behavior, because depending on whether an existing Functor
instance is already in scope, a Monad instance will either create one or
not.
John
--
John Meacham - repetae.netjohn
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
