[Haskell-cafe] Badly designed Parsec combinators?

Juan Carlos Arevalo Baeza jcab.lists at JCABs-Rumblings.com
Thu Feb 16 07:22:40 EST 2006

Tomasz Zielonka wrote:
> On Sun, Feb 12, 2006 at 06:22:46AM -0800, Juan Carlos Arevalo Baeza wrote:
>>   This brings me to wonder also if it'd be possible for the compilers 
>> to add a little bit more smarts to the "do" notation syntax, so that 
>> it'll add the return () at the end if it's missing. Maybe too much to 
>> ask of the Haskell crowd :).
> I wouldn't like that, as do-expressions without return at the end
> can be convenient. They can also make your intent clearer for
> other programmers and perhaps also the compiler, especially when
> you want to write tail-recursive monadic code (assuming a suitable
> monad and/or a sufficiently smart compiler).

   Right, I understand and share that thought. But that's not what I 
meant. I really didn't explain the way I should, and I didn't think it 
through. What I was proposing needs to be implemented not as an addition 
to the do-syntax sugar, but as something the compiler does to monads 
when matching their type. Take for instance this function:

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 (). But 
that function as written will not compile (with my proposed modification 
to "optional"), and so we have to manually add the "return ()" at the end.

   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).

   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 "!"

   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 ()".

   All I'm saying is that I wish the language and the compiler would 
take care of that for me.

   Hence what I said: maybe too much for the Haskell crowd to start 
playing games with the type system like this. It resembles a lot the 
automatic conversions that C++ does. I agree Haskell can't have those in 
any form, but still... "return ()"...



More information about the Haskell-Cafe mailing list