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 (06:15)
From: skaller <skaller@o...>
Subject: Re: [Caml-list] GC and file descriptors
On Thu, 2003-11-20 at 04:36, Brian Hurt wrote:
> On 20 Nov 2003, skaller wrote:

> 3) While there are programs which will terminate with lazy evaluation that 
> won't terminate with strict evalulation, such programs mainly appear only 
> as counter examples.  If I know that I'm in a strict evaluation language, 
> I just don't do that ("Doctor- it hurts when I do this!" "Well, don't do 
> that then!").

For me it is hard to say, since I don't use a lazy language,
*but* there are times when I am thinking of 'streaming'
things rather than building whole data structures in
memory and transforming them in phases.

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

So I would not be so quick to discredit lazy
evaluation as a bad performer, I guess 
considerable experience would be needed
first to form a judgement.

One indication I have is that Charity is lazy.
I don't know if that is an arbitrary choice
or necessary for a reasonable representation
of coinductive data types. Anyone know anything
aboy the connection between lazy evaluation and
coinductive types?

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