Browse thread
[Caml-list] Wasn't O'Caml a functional language?
- Alessandro Baretta
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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