Am Samstag 30 Mai 2009 02:04:29 schrieb Bartosz Wójcik:

On Friday 29 May 2009 22:10:51 Bryan O'Sullivan wrote:

...

...

myFloat = try (symbol "-" >> float >>= return . negate) <|> try float <|> (integer >>= return . fromIntegral)

Any time you see ">>= return .", something is being missed. Use liftM or <$> instead, i.e. "fromIntegral <$> integer" instead of "integer >>= return . fromIntegral".

I don't undersdand what is being missed.

liftM f m1 = do { x1 <- m1; return (f x1) } so liftM fromIntegral integer will result the same. Is it then not just a convenience?

Even, desugaring the definition of liftM, we get liftM f m1 = m1 >>= return . f or, eta-reducing, liftM f= (>>= return . f) It's a matter of style and readability.

Bartek

On Fri, May 29, 2009 at 5:04 PM, Bartosz Wójcik wrote:

I don't undersdand what is being missed.

Brevity.

liftM f m1 = do { x1 <- m1; return (f x1) } so liftM fromIntegral integer will result the same.

Yes, and there's less code to read if you use liftM or <$>, hence fewer moving parts to understand.

2009/05/30 Bartosz Wójcik :

...reading RWH I could not memorize what those liftM funtions meant.

The basic one, `liftM`, means `fmap`, though specialized for functors that are monads. Prelude Control.Monad> :t liftM liftM :: forall a b (m :: * -> *). (Monad m) => (a -> b) -> m a -> m b Prelude Control.Monad> :t fmap fmap :: forall a b (f :: * -> *). (Functor f) => (a -> b) -> f a -> f b I think we have `liftM` either to help the inferencer or due to the absence of a `(Functor m)` constraint in the definition of the `Monad` typeclass. -- Jason Dusek

Jason Dusek wrote:

2009/05/30 Bartosz Wójcik :

...

...reading RWH I could not memorize what those liftM funtions meant.

The basic one, `liftM`, means `fmap`, though specialized for functors that are monads.

Prelude Control.Monad> :t liftM liftM :: forall a b (m :: * -> *). (Monad m) => (a -> b) -> m a -> m b Prelude Control.Monad> :t fmap fmap :: forall a b (f :: * -> *). (Functor f) => (a -> b) -> f a -> f b

Category theoretically, all the following are (or should be!) equal: fmap, (<$>), liftA, liftM. Type theoretically, they differ in whether they require Functor, Applicative, or Monad. Unfortunately there's a clash between the current types and their CT backing. That is, Monad doesn't require Applicative (or Functor), so people will often use liftM to avoid extra type constraints. Operationally, fmap and (<$>) are potentially more efficient. The liftA and liftM functions re-engineer fmap by using pure/(<*>) or return/ap, thanks to CT. The (<$>) function is just an alias for fmap. But the fmap function is part of a type class and so it may have a specific implementation which is more efficient than the generic one provided by CT. -- Live well, ~wren