Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
environment idiom
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-12-13 (12:48)
From: Thomas Fischbacher <Thomas.Fischbacher@P...>
Subject: Re: [Caml-list] environment idiom

On Mon, 13 Dec 2004, Jacques Garrigue wrote:

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

Deep in my stomach I have the feeling that precisely this is the case, and 
it might well involve some additional syntactic sugar. The problem is 
perhaps that the imperative way of coding - which (if we admit it) we all 
are at least somewhat used to - blocks our view onto more reasonable ways
to tackle this issue. As one says, a genius is someone who is the first to 
do something obvious in the right way, and it will perhaps take a genius 
to find the proper way to express IO plan composition in a strikingly 
beautiful way which in particular does not suffer from naive imperative 

At present, it seems as if there were problems of both types: those where 
most of the desired functionality can be easily expressed in a purely 
functional way, which is hooked into an otherwise small IO plan, and those 
where a large and highly sophisticated IO plan makes use of only very 
few and small purely functional helpers. Somehow, this disparity "feels" 
quite strange.

These are just a few random thoughts on an issue that is perhaps not yet 
sufficiently well understood to reach a final conclusion. Considering that 
the monadic point of view only entered the scene quite recently, I hope 
that in a few years, we have a much better understanding of all these 

regards,                   (o_
 Thomas Fischbacher -  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)