English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: practical functional programming
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-11-08 (16:21)
From: Hao-yang Wang <hao-yang_wang@f...>
Subject: Re: practical functional programming
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 

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

Hao-yang Wang