Difference between revisions of "Talk:Functor hierarchy proposal"
(taking return out of Applicative) |
|||
(4 intermediate revisions by 4 users not shown) | |||
Line 2: | Line 2: | ||
class (Idiom f) => Monad f where |
class (Idiom f) => Monad f where |
||
− | fmap f m = m >>= return . f |
+ | fmap f m = m >>= return . f -- or ap . return ? |
ap mf mv = mf >>= \f -> mv >>= \v -> return $ f v |
ap mf mv = mf >>= \f -> mv >>= \v -> return $ f v |
||
(>>=) :: f a -> (a -> f b) -> f b |
(>>=) :: f a -> (a -> f b) -> f b |
||
Line 9: | Line 9: | ||
[[User:Serhei|Serhei]] 15:24, 29 January 2006 (UTC) |
[[User:Serhei|Serhei]] 15:24, 29 January 2006 (UTC) |
||
+ | |||
+ | :You can't put defaults for one class in another. Though that could be another proposal. —[[User:Ashley Y|Ashley Y]] 21:02, 29 January 2006 (UTC) |
||
+ | |||
+ | ::Wasn't this part of John Meacham's class system proposal? What happend to this? -- [[User:Wolfgang Jeltsch|Wolfgang Jeltsch]] 19:25, 2 February 2006 (UTC) |
||
+ | |||
+ | <hask><*></hask> should really be merged with <hask>ap</hask>, right ? |
||
+ | (Btw, why such a symmetric operator symbol as <hask><*></hask> ? <hask><*</hask> or some other assymetric one would be better .. even plain <hask>`ap`</hask> is not so bad, imho.) |
||
+ | |||
+ | Also, it would be nice to change <hask>sequence</hask>, <hask>sequence_</hask>, <hask>mapM</hask> and <hask>mapM_</hask> to only require <hask>Applicative</hask> instead of <hask>Monad</hask>. (Or one could merge these four into something like <hask>Data.FunctorM.FunctorM</hask>, which should use <hask>Applicative</hask> anyway.) -- [[User:StefanLjungstrand|StefanLjungstrand]] 10:18, 3 November 2006 (UTC) |
||
+ | |||
+ | ---- |
||
+ | |||
+ | I think it makes sense to take return out of Applicative. Either into a separate step between Functor and Applicative, or into a new class altogether: |
||
+ | <haskell> |
||
+ | class Boxable f where |
||
+ | return :: a -> f a |
||
+ | class (Functor f, Boxable f) => Applicative f where |
||
+ | ... |
||
+ | </haskell> |
||
+ | But maybe this is just overengineering. |
||
+ | |||
+ | [[User:Twanvl|Twanvl]] 21:46, 15 January 2007 (UTC) |
Latest revision as of 21:46, 15 January 2007
Um, it would be good if it was something like:
class (Idiom f) => Monad f where fmap f m = m >>= return . f -- or ap . return ? ap mf mv = mf >>= \f -> mv >>= \v -> return $ f v (>>=) :: f a -> (a -> f b) -> f b
Or am I missing the point?
Serhei 15:24, 29 January 2006 (UTC)
- You can't put defaults for one class in another. Though that could be another proposal. —Ashley Y 21:02, 29 January 2006 (UTC)
- Wasn't this part of John Meacham's class system proposal? What happend to this? -- Wolfgang Jeltsch 19:25, 2 February 2006 (UTC)
<*>
should really be merged with ap
, right ?
(Btw, why such a symmetric operator symbol as <*>
? <*
or some other assymetric one would be better .. even plain `ap`
is not so bad, imho.)
Also, it would be nice to change sequence
, sequence_
, mapM
and mapM_
to only require Applicative
instead of Monad
. (Or one could merge these four into something like Data.FunctorM.FunctorM
, which should use Applicative
anyway.) -- StefanLjungstrand 10:18, 3 November 2006 (UTC)
I think it makes sense to take return out of Applicative. Either into a separate step between Functor and Applicative, or into a new class altogether:
class Boxable f where
return :: a -> f a
class (Functor f, Boxable f) => Applicative f where
...
But maybe this is just overengineering.
Twanvl 21:46, 15 January 2007 (UTC)