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
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 1999-10-03 (22:46)
From: William Chesters <williamc@d...>
Subject: OCaml et l'évaluation paresseuse
David Jemmi writes:
 > Pourquoi OCaml (ou caml) n'utilise pas l'évaluation paresseuse par défaut ??

Two problems.  Firstly,

 > (pour les problèmes de performances, je pense qu'un bon optimiseur suffit).

is unfortunately not true.  For instance Clean, which supports both
strict and lazy evaluation, does so in entirely different ways, and
you are warned that the latter is much slower.

   The basic point is that a strict language like ocaml is just a
fancy version of assembler or C---a function call really is a CALL
instruction (and a higher order call is a "call *%ecx").  Since the
computational model presented to the programmer is essentially just
that of the underlying CPU, it's easy to write fast code.  The only
concession made to "abstraction" is the garbage collector.

   If instead you present the programmer with a different
computational model, however elegant, you make it impossible for her
to "talk the CPU's language", so she is relying on the compiler to
make the necessary transformations; and that turns out to be very,
very difficult, like proving theorems.

   Another point is that although lazy evaluation is very exciting and
fun to start with, you do quickly come to realise that for nearly all
purposes, the imperative idioms into which (you hope) the compiler is
going to compile your lazy code are in fact just as convenient, nearly
as flexible and often easier to understand.

   I think it's the big lesson of the 80s: abstraction is intoxicating
but, as with alcohol, you have to be careful.  Cf. microkernels, 4GLs,
OSI, ...