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
[Caml-list] GC and file descriptors
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-11-20 (07:37)
From: David Brown <caml-list@d...>
Subject: Re: [Caml-list] GC and file descriptors
On Thu, Nov 20, 2003 at 04:14:36PM +1100, skaller wrote:

> Whilst you can do that in a strict language like
> Ocaml I would guess it is (at least a bit more) 
> *automatic* in a lazy language like Haskell.
> I guess that would be a major productivity
> and performance boost -- the code is easier
> to write, and far less memory is required
> (since for example only a small local part
> of a list will exist at any time, the not
> yet needed part is not yet built, and the
> already used part is not reachable and 
> thus deallocated).

My brief experience with Haskell:

  - The lazy evaluation is very helpful, precisely for what you
    describe.  Code has the potential to be clearer, since interfaces
    are simpler.  Time need not be specified.

  - I also found it is easy to create space leaks, and very hard to find
    them.  Since flow is not specified directly in the language, I found
    it difficult to develop an intuition for liveness.

  - The lazy evaluation is a performance hit, but a fairly constant one.
    The good compilers tend to write strict code for small cases, but
    large portions of the code run a lazy fashion.  This adds quite a
    bit of burden to the GC as well.  Essentially, most data structures
    include closures for computing results.  There is extra overhead to
    evaluate the closures, as well as the necessity to allocate/collect
    the data associated with them.

I do periodically go back to Haskell, because there is just something
neat feeling about it.  But, I have not encountered a language that is
so intuitive to program as Ocaml.


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