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