From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id AAA18696 for caml-redistribution; Mon, 4 Oct 1999 00:46:48 +0200 (MET DST)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA07549 for <caml-list@pauillac.inria.fr>; Sun, 3 Oct 1999 09:26:59 +0200 (MET DST)
Received: from smtp1.hetnet.nl (smtp1.hetnet.nl [145.7.225.1])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id JAA19601
	for <caml-list@inria.fr>; Sun, 3 Oct 1999 09:26:58 +0200 (MET DST)
Received: from hetnet.nl ([194.151.104.154]) by smtp1.hetnet.nl  with Microsoft SMTPSVC(5.5.1877.977.9);
	 Sun, 3 Oct 1999 09:24:13 +0200
Received: from beertje.william.bogus ([195.121.168.91]) by hetnet.nl  with Microsoft SMTPSVC(5.5.1877.327.32);
	 Sun, 3 Oct 1999 09:28:23 +0200
Received: (from williamc@localhost)
	by beertje.william.bogus (8.9.3/8.8.7) id VAA10752;
	Sat, 2 Oct 1999 21:38:05 +0200
From: William Chesters <williamc@dai.ed.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Sat,  2 Oct 1999 21:38:05 +0200 (CEST)
To: "David Jemmi" <david.jemmi@pactenovation.fr>
Cc: "CAML Mailing list" <caml-list@inria.fr>
Subject: OCaml et l'évaluation paresseuse
In-Reply-To: <002001bf0c03$b9e522a0$490ad227@aladin>
References: <002001bf0c03$b9e522a0$490ad227@aladin>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14326.22713.12780.605064@beertje.william.bogus>
Sender: weis

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