From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA13329 for caml-red; Wed, 8 Nov 2000 17:21:45 +0100 (MET)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA14744 for <caml-list@pauillac.inria.fr>; Tue, 7 Nov 2000 00:05:28 +0100 (MET)
Received: from ftp.filemaker.com (ftp.filemaker.com [192.35.50.27])
	by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id eA6N5R119735
	for <caml-list@inria.fr>; Tue, 7 Nov 2000 00:05:27 +0100 (MET)
Received: from imap.filemaker.com (imap.filemaker.com [17.184.4.101])
	by ftp.filemaker.com (8.9.0/8.9.0) with ESMTP id PAA27364;
	Mon, 6 Nov 2000 15:05:14 -0800 (PST)
Received: from [17.184.5.111] ([17.184.5.111])
	by imap.filemaker.com (8.9.3/8.9.0) with SMTP id PAA15186;
	Mon, 6 Nov 2000 15:05:16 -0800 (PST)
Message-Id: <200011062305.PAA15186@imap.filemaker.com>
Subject: Re: practical functional programming
Date: Mon, 6 Nov 2000 15:10:40 -0800
x-sender: hao-yang_wang@mail.filemaker.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Hao-yang Wang <hao-yang_wang@filemaker.com>
To: <caml-list@inria.fr>
cc: "Chris Hecker" <checker@d6.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Sender: weis@pauillac.inria.fr

When you need to preserve the mutation history (or multi-history) of the 
data, Okasaki's data structures are useful. For other cases, I see 
nothing wrong in using mutable data structures.

>So, what does all this trouble buy you?  I vaguely understand how a purely 
>functional language like Haskell might be more amenable to analysis and 
>proof than C, but people jump through hoops to get that (read: IO monads 
>in Haskell, Okasaki's datastructures).  Is it worth it?  Clearly the caml 
>folks didn't think so because the standard library datastructures are 
>destructively modifying.

Haskell is a lazy language, with which we are supposed to ignore when (or 
whether) an expression is going to be evaluated, at least most of the 
time. As the result we have to give up all the side effects (i.e., I/O 
and destructive data updates), because we have no idea on the order in 
which these side effects occur. On the other hand, the ML family is 
strict.

I do not shy away from using side effects with o'caml. However, when I 
look back to the o'caml programs I wrote, I am always surprised in how 
pure they turned out to be: The side effects flock to a few places, 
usually at the top-most functions.

For a nice example on how the imperative features can help in writing a 
correct o'caml program, look at <http://caml.inria.fr/icfp99-contest/>.

Cheers,
Hao-yang Wang