[Haskell-cafe] Badly designed Parsec combinators?

[John Meacham]

On Thu, Feb 16, 2006 at 04:22:40AM -0800, Juan Carlos Arevalo Baeza wrote:
>   But... the thing is, if we have any "do" statement, or any monad 
> whatsoever, which does not return (), and the program needs it to return 
> () in order to be able to match its type, that transformation is always 
> trivial. It just has to add ">> return ()" to it. () is special that 
> way, because there's only one possible value, and monads are also 
> special already (do-notation, for instance).

How do you know what type the do statement returns in general? in
haskell, type inference goes both directions, deciding the type at any
point depends not just on what routine you are calling but the context
it is called in. 

>   Again that doesn't compile, because "when" requires a ()-returning 
> monad as its second parameter, but the "string" parser returns "String". 
> Same thing with if-then-else, when used to switch IO actions and such: 
> the IO actions must fully match in type, even if the returned value will 
> be discarded, and again that can be trivially resolved by adding the 
> "return ()".

This is a straight up bug in the definition of when I hope we fix. it
should have type

when :: Bool -> IO a -> IO ()
when = ...

        John


-- 
John Meacham - ⑆repetae.net⑆john⑈