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 PAA08653 for caml-red; Thu, 12 Oct 2000 15:57:48 +0200 (MET DST)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA07901 for <caml-list@pauillac.inria.fr>; Thu, 12 Oct 2000 15:26:40 +0200 (MET DST)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e9CDQaX08349;
	Thu, 12 Oct 2000 15:26:36 +0200 (MET DST)
Received: (from herbelin@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA07988; Thu, 12 Oct 2000 15:26:35 +0200 (MET DST)
From: Hugo Herbelin <Hugo.Herbelin@inria.fr>
Message-Id: <200010121326.PAA07988@pauillac.inria.fr>
Subject: Re: Undefined evaluation order: define it for constructors ?
In-Reply-To: <20001012173521W.garrigue@kurims.kyoto-u.ac.jp> from Jacques Garrigue at "Oct 12, 100 05:35:21 pm"
To: garrigue@kurims.kyoto-u.ac.jp (Jacques Garrigue)
Date: Thu, 12 Oct 2000 15:26:35 +0200 (MET DST)
Cc: caml-list@inria.fr
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: weis@pauillac.inria.fr


  As Jacques Garrigue underlines it, discussions are less about the
evaluation order of arguments of functions that those of tuples and
the latter looks like strictly arbitrary (I guess it was initially
chosen right-to-left by consistency with the evaluation order of
arguments which is not arbitrary). To make evaluation of tuple LR or
RL is then just a matter of principle... and to guarantee it for the
user also!

  It is sometimes useful to do side-effects with "List.map" (or
"Array.map"): it leads to code more readable than if using
"fold_left". I'd be happy if the evaluation order of "map" in the
interface were specified, as it is the case (for a good reason) for
the "iter" functional. 

  Furthermore, in O'Caml (in contrast with Caml-Light -- a teaching
language!), List.map and Array.map are written in such a way they
evaluate as we write lists, i.e. from left to right! Is it not
the right time to say it?

  Regarding the evaluation order of arguments for functions, is it
only to adapt polymorphism with the stack-model on which the bytecode
interpreter relies? If so, what would be the overhead if the frame
were first allocated then arguments evaluated LR but put in the frame
in the _reverse_ way in order (possibly incremental) capture of
arguments by the function continues to work.

                                                  Hugo