Re: [Caml-list] environment idiom

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

From: Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>
> On Mon, 13 Dec 2004, Jacques Garrigue wrote:
> 
> > > Of course, it's possible to just forget about all that and fall back to 
> > > transliterating imperative code to IO monad code, but it is just as well 
> > > possible to find the sum of all the numbers from 1 to 1000 using the 
> > > following piece of Maple code:
> > 
> > You make me curious. Most of the code I've seen using the IO monad (or
> > the state transformer monad) was just transliterating imperative to
> > monadic code. Of course using closures, but not that much, and you can
> > certainly do that in an impure functional language also.
> 
> First, I should perhaps mention that in my point of view, John does have a 
> valid point in what he says. It's only that he expressed it in a way I 
> just *cannot* agree with.

OK, so probably we almost agree.
Three days ago I was about to answer John that indeed he has a good
point, but he seems to ignore completely the other advantages of
monads, like the fact you can cleanly mix stateful code with pure
code, keeping the two separate.

> > So what is so incredible about the IO monad?
> 
> There is nothing "in-credible" about it. It is just plainly nothing else 
> as working with values that describe "plans" to do IO. We do have a magic 
> place that can bring such plans to life, causing them to be executed, but 
> from the pure Haskell point of view this is not relevant. All we do is to 
> construct plans how to do IO.

So maybe the problem goes back to the compositional vs. pointwise view
of things. While the compositional view is nice, at some level of
detail I find it simpler to reason pointwise (even when purely
functional).
My real curiosity was about the kind of compositional abstractions one
would use with stateful computations. It seems to me that the presence
of state itself makes it more difficult to compose cleanly. At least,
types help you less: they let you now that there is state around, but
not the detail of how this state is used (maybe I'm not up-to-date
with recent Haskell.)

> > Of course according to your definition this contains nothing that is
> > not referentially transparent once you've taken the syntactic sugar.
> 
> Precisely. To go a bit more into detail:

No need to explain: I know this is referentially transparent :-)
My only point was that it doesn't _look_ so.

> In a certain sense, this "do" notation - which is NOT a special extension 
> of the powers of pure, functional haskell but only a short-hand notation 
> for things that can be spelled out explicitly - is "poison" that allows 
> one to "just hack one's imperative thoughts into haskell without 
> even having know about the abstract point of view". This is a bit like 
> FORTRAN programmers asked to adjust themselves to C showing the attitude 
> that "at least, they can forget all that for/while/etc. mumbo-jumbo and 
> do everything with goto, as they are used to".

I wonder whether this is really so.
Some programs without the do notation would be much harder to read.
Do you really think they can all be rewritten to cleaner alternative
code?

> Coming back to the original question, which was whether one may "just 
> stick in some monadic stuff to get a notion of an `environment'", I'm 
> inclined to say that from the purely functional point of view, this 
> perhaps is not a good idea, as this is not just "a minor change to the 
> code" but changes pretty much anything of its original properties.

Having worked on parameterization systems a long time ago, I can only
agree.
The trouble with the monadic view of environment is that you quickly
end up making all your functions monadic, introducing some
sequentiality which may have no reason to be. While being no expert of
the question, this seems to be a tendency of monads: they are
so comfortable that they tend to pollute everything, diluting the
advantage of knowing exactly what is functional. But how can you stop
people from going the easy way?

       Jacques Garrigue