Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Wasn't O'Caml a functional language?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Alessandro Baretta <alex@b...>
Subject: [Caml-list] Wasn't O'Caml a functional language?
First of all, allow me to RTFM myself before anybody else 
does. I just spent the last hour or so tracking down a bug 
caused by the "procedural-style" side-effect in Queue.iter: 
the queue is actually emptied by that function. Now, if 
O'Caml is a functional language, and Queue.iter is a 
functional iterator, why is there a need for that very 
counterintuitive side-effect? If I use List.iter on a list, 
I do not expect it to flush my list of all it's contents. 
The same with a Hashtbl.iter, and in general with all 
functional iterators, which are the very heart of the 
standard library.

In my opinion, "The Right Way (TM)" to use datastructures in 
O'Caml and in functional languages in general is to build 
them, iterate non-destructively over them as many times as 
necessary, and finally let the GC reclaim them when they are 
no longer accessible from the live scope. What makes this 
approach much simpler to handle, much more intuitive to 
understand and less intricate to debug, is that data 
structure aliasing does not have to be explicitly taken into 
account. On the other hand, if one uses iterators with 
side-effects and the data structures are aliased--as was my 
case in my application, until I figured out what was going 
wrong--all sorts of weird non-local bugs can appear, and 
tracking them down can take quite a few runs of ocamldebug.

Concluding, let me "break a spear"--as we say in Italian--in 
favor of a purely functional standard library, where such 
datastructures as Queue.t's and the like can be freely 
aliased without a second thought.

Cheers, and back to work...

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners