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

[Benjamin Franksen]

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