Frederik Eaton wrote:
I think this is a good idea. I like the inline "<-", or maybe
something like "@".
The operator-section notation (<- expr) has the big advantage of being
unlikely to collide with any other syntax proposals.
I'm not sure what you intend to do about nested "do" statements,
though. If they correspond to different monads, I might want to have a
'borrow' in the inner "do" statement create a lifted expression in the
outer "do" statement.
In such cases you almost certainly wouldn't want to use this notation
anyway. It's confusing enough with a single monad.
As an experiment I tried rewriting some monadic code from one of my projects
(Reform) using the (<- expr) syntax. It was interesting. Some points:
* Most of my uses of <- could be replaced with the inline form. In
some cases it seemed like a bad idea, because the intermediate
variable name was useful as documentation. In the other cases I'd
obviously chosen a meaningless intermediate variable name just to
get around the lack of a feature like this one.
* I found myself writing "do return" a lot, which isn't a combination
you usually see in Haskell code. It felt odd, but perhaps you'd get
used to it.
* The new syntax is really nice as a replacement for the annoyingly
common "x <- foo ; case x of..." idiom that I've always disliked.
* The increased similarity to programming in an eager language was
startling at times. I'm just not used to thinking eagerly when I
write Haskell, even though I do it all the time in other languages.
* There are tricky corner cases. For example,
x <- getByte
if x < 128
then return x
else return (x - 128) * 256 + (<- getByte)
doesn't do what it's probably intended to do: the second byte will
be read even if x < 128. You have to write "else do return"
instead of "else return". I'm afraid this would be easy to get
wrong. It wouldn't be hard to make the translation assume an
implicit do at the branches of if and case statements, but this
wouldn't always be what you'd want. Even worse is that short-
circuiting && and || don't work as they do in eager languages.
So on reflection I'm not sure I think this proposal is a good idea. I
probably wouldn't be able to write or read code in this style without doing
manual desugaring in my head, which takes away much of the appeal. But it
might be worth adding if people can be trusted to use it judiciously.
-- Ben
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
