There's been lots of interesting stuff on this thread. Does anyone feel up to summarizing it on a Wiki page, for others to polish? At least part of that page should comprise a compact specification of what the (<- ) proposal is; but there have been lots of other suggestions. Otherwise it'll all get submerged by next month's excitements. Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- | bounces@haskell.org] On Behalf Of Benjamin Franksen | Sent: 09 August 2007 21:31 | To: haskell-cafe@haskell.org | Subject: [Haskell-cafe] Re: Re: a regressive view of support for | imperative programming in Haskell | | 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 | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe