[Haskell-cafe] Re: Re: a regressive view of support for imperative programming in Haskell

[Simon Peyton-Jones]

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 at haskell.org [mailto:haskell-cafe-
| bounces at haskell.org] On Behalf Of Benjamin Franksen
| Sent: 09 August 2007 21:31
| To: haskell-cafe at 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe