David Roundy wrote:
On Thu, Aug 09, 2007 at 08:45:14PM +0200, Benjamin Franksen wrote:
David Roundy wrote:
Several times since reading the beginning of this discussion I've wished I had the new syntax so I could write something like:
do if predicateOnFileContents (<- readFile "foo") then ...
instead of either
do contents <- readFile "foo" if predicateOnFileContents contents then ...
or (as you'd prefer)
readFile "foo" >>= \contents -> if predicateOnFileContents contents then ...
Isn't this problem, namely being forced to name intermediate results, also solved by some sort of idiom bracket sugar, maybe together with the lambda case proposal? I would prefer both very much to the proposed (<- action) syntax for the same reasons that e.g. Jules Bean nicely summarized.
I'm not familiar with the lambda case proposal,
http://hackage.haskell.org/trac/haskell-prime/wiki/LambdaCase or, quoting from a recent post by Stefan O'Rear in this thread:
I think the CaseLambda proposal on the Haskell' wiki solves this one nicely.
mexpr >>= case of p1 -> branch1 p2 -> branch2
You still have to use >>=, but you don't have to name the scrutinee (and names are expensive cognitively).
i.e. your example would become fmap predicateOnFileContents (readFile "foo") >>= case of True -> ... False -> ... (use liftM instead of fmap, if you prefer)
and don't know what you mean by idiom bracket sugar,
As has been already mentioned in this thread, in http://www.soi.city.ac.uk/~ross/papers/Applicative.html Conor McBride and Ross Paterson invent/explain a new type class that is now part of the base package (Control.Applicative). They also use/propose syntactic sugar for it, i.e. pure f <*> u1 <*> ... <*> un ~~> (| f u1 ... un |) (I just made up the symbols '(|' and '|)', the concrete syntax would have to be fixed by people more knowledgeable than me.) As to the pros and cons of (<- action) proposal, I think everything has been said. I'd vote for giving IdiomBrackets and/or LambdaCase a chance for being implemented, too, so we can try and evaluate different ways to simplify monadic code. One reason why I like IdiomBrackets is that they are more generally applicable (no pun intended ;:) i.e. they would work not just for Monads but for anything in Applicative. (Of course, that is also their weakness.) Similary, LambdaCase has more applications than just simplifying monadic code by avoiding to name an intermediate result. Cheers Ben