Juan Carlos Arevalo Baeza wrote: > myParser :: Parser () > myParser = > do string "Hello" > optional (string ", world!") > > It makes no sense for myParser to generate any values, especially not > the result from the optional statement, so it is set to return ().
Don't you think this will interfere somehow with type inference? I
wouldn't like a function that might decide to throw away its result if
(erroneously) used in a context that wouldn't need it. I also think
almost every function has a sensible result, and written with the right
combinator, can return it without too much hassle. So I'd probably
write:
yourParser :: Parser String
yourParser = liftM2 (++) (string "Hello")
(option "" (string ", world!")
I also find it very convenient to have a combinator that does a bind and
return the unmodified result of the first computation. With that you
get:
(*>) :: Monad m => m a -> m b -> m a
m *> n = do a <- m ; n ; return a
ourParser :: Parser String
ourParser = string "Hello" *> optional (string ", world!")
Therefore, implicit (return ()) is selsdom useful, has the potential to
cause annoying silent failures and is generally not worth the hassle.
> Another case where I encounter this is with the "when" function:
>
> myParser2 :: Bool -> Parser ()
> myParser2 all =
> do string "Hello"
> when all $
> do string ", world"
> string "!"
A better fix would be more flexible when:
when :: Monad m => Bool -> m a -> m (Maybe a)
when True m = Just `liftM` m
when False _ = return Nothing
...which is quite similar to the proposed change to Parsec's 'optional'.
I'd support both.
> It resembles a lot the
> automatic conversions that C++ does.
I'm more reminded of Perl...
Udo.
--
Avoid strange women and temporary variables.
signature.asc
Description: Digital signature
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
