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 ()"...
Thanx!
JCAB
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
