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

[David Roundy]

On Thu, Aug 09, 2007 at 02:08:20PM +0100, Jules Bean wrote:
> David Roundy wrote:
> >On Wed, Aug 08, 2007 at 02:20:39PM -0400, Paul Hudak wrote:
> >As long as the sugar has a pretty obvious desugaring (which I seem to
> >recall it did), I don't see how it's likely to make things worse.  And
> 
> Some people are arguing that the desugaring isn't obvious.

That's a reasonable objection (although I disagree).

> Although I like the proposal to start with, I am beginning to be 
> convinced by those arguments.
> 
> For example:
> 
> > do foo x
> 
> can be simplified to
> 
> > foo x
> 
> under the new proposals
> 
> > do x <- bar y
> >    foo x
> 
> would shorten to
> 
> > do foo (<- bar y)
> 
> and now you really really want to remove the do, to get simply
> 
> > foo (<- bar y)
> 
> but that would be illegal. The new sugar is going to remove all kinds of 
> substitution and simplification lemmas that we have got used to.

I guess I'd just have to argue that like the <- notation, the (<- )
notation is *part* of the do notation.  Just as you can't pull a <- out of
a do loop and expect it to behave identically, you can't do the same with a
(<- ).  To me, the similarity with existing do-dependent syntax (and it
helps that except for pattern guards, <- is *only* used within a do block.

> There is also the fact that if :
> 
> foo x = bar x x
> 
> then you call foo monadically as in
> 
> do foo (<- baz)
> 
> You can no longer "replace foo with its definition", because if replace 
> that with
> 
> do bar (<- baz) (<- baz)
> 
> ...that means something rather different :(

Again, this seems obvious, and it doesn't seem like "replace foo with its
definition" is something I think of.

> A third example is with nested dos:
> 
> do x <- bar y
>    baz
>    something $ do foo x
> 
> is not the same as
> 
> do baz
>    something $ do foo (<- bar y)

Again, it all comes down to whether the "find the nearest do" is obvious.
It seems pretty obvious to me.  And I like the idea of someone just
implementing this, and then those of us to whom it appeals can try it.
I've longed for something like this (mostly for monadic ifs and cases) for
quite a while now...
-- 
David Roundy
Department of Physics
Oregon State University