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

[Brandon Michael Moore]

On Thu, Aug 09, 2007 at 11:52:17AM -0700, David Roundy wrote:
> On Thu, Aug 09, 2007 at 02:08:20PM +0100, Jules Bean wrote:

*snip*

> > 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...

Funny, I've been longing for the monadic case (and if) for quite a while.
A mondic case is simple, it's handy, and you don't have to worry about
lots of interactions

caseM e of alts ==> e >>= \x -> case x of alts

I'm convinced this would be plenty useful on its own, and also that
trying to design any more comprehensive syntax quickly gets really
tricky.

The basic problem seems to be that functions can expect either monadic
or pure arguments, and return pure or monadic values, so there are at
least three possible conversion you might want at each application
(considering pure<->pure and monadic<->monadic the same). Defaulting
to "make things work" requires type information, and doesn't seem
nearly so simple if you consider that programmers might actually want
to pass around actions of the monad they are running in as values
(Setting GUI callbacks, using [] for String processing, etc).

Actually, deciding which tranformation gets juxtaposition and how to
recurse into subterms seems to give a design space that might have
reasonable solutions. More on that in a latter message.

> > 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.

One of the great things about haskell is how completely naive
you can be when you "replace foo with its definition", and still do
valid equational reasoning.

It would be sad if substituting a parenthesized
subterm of something that looked like an expression wasn't valid.
(expanding a definition can change sharing, but at least it's denotationally
equivalent).  The only slightly tricky things now are remembering
that x <- exp does not define x to be exp, and what to expand a class method
to. I think I'd be happier if there was some bracketing around the
expression to be transformed, to warn you to again be cautious and fearful
about transforming your code.

Brandon