From: William Chesters <williamc@dai.ed.ac.uk>
Date: Sat, 2 Oct 1999 21:38:05 +0200 (CEST)
To: "David Jemmi" <david.jemmi@pactenovation.fr>
Subject: OCaml et l'évaluation paresseuse
In-Reply-To: <002001bf0c03$b9e522a0$490ad227@aladin>
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, ...
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:25 MET