From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <garrigue@math.nagoya-u.ac.jp>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE,
	MAILTO_TO_SPAM_ADDR,SPF_SOFTFAIL autolearn=disabled version=3.1.3
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 8044BBC6C
	for <caml-list@yquem.inria.fr>; Sat, 19 Jan 2008 03:32:57 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8CAGfwkEeCNhAB/2dsb2JhbACueQ
X-IronPort-AV: E=Sophos;i="4.25,219,1199660400"; 
   d="scan'208";a="6927757"
Received: from kurims.kurims.kyoto-u.ac.jp ([130.54.16.1])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 19 Jan 2008 03:32:56 +0100
Received: from localhost (orion [130.54.16.5])
	by kurims.kurims.kyoto-u.ac.jp (8.13.8/8.13.8) with ESMTP id m0J2Wp2h004814;
	Sat, 19 Jan 2008 11:32:51 +0900 (JST)
Date: Sat, 19 Jan 2008 11:32:43 +0900 (JST)
Message-Id: <20080119.113243.267873825.garrigue@math.nagoya-u.ac.jp>
To: thelema314@gmail.com
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Strange performances
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
In-Reply-To: <4790D9FC.5090108@gmail.com>
References: <9d3ec8300801172339j38bf734dm5b84f951a4342188@mail.gmail.com>
	<20080118.181206.85503086.garrigue@math.nagoya-u.ac.jp>
	<4790D9FC.5090108@gmail.com>
X-Mailer: Mew version 4.2 on Emacs 22.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam: no; 0.00; segfault:01 ocaml's:01 ocaml's:01 compiler:01 camlers:01 bytecode:01 constructors:01 ocaml:01 cheers:01 edgar:98 wrote:01 stack:01 syntactic:01 caml-list:01 functions:01 

From: Edgar Friendly <thelema314@gmail.com>
> Jacques Garrigue wrote:
> > 
> > This is why I sent an erratum. The cause for the segfault was not the
> > array access, but the stack overflow, which occured due to ocaml's
> > peculiar evaluation order.
> 
> Is there any case where ocaml's "peculiar evaluation order" results in
> any benefit other than slightly simpler code at the compiler level?  I
> understand that people shouldn't depend on evaluation order, but it
> seems that people fall into this trap often.  And even extremely
> experienced camlers (if you permit this characterization of you) forget
> this behavior.

Actually, the bytecode optimization is related to the evaluation order
of functions, not data structures. So it would be perfectly possible
to create blocks from left to right, without losing this optimization.
I thought about it once, since most errors seem actually related with
data construction rather than function calls. Such an order would even
generate slightly more compact code for modules (which clearly have
to be evaluated from left to right.)

The downside of such an approach would be different evaluation orders
for data constructors and functions. There is no theoretical problem
in it, since they form different syntactic classes in ocaml, but
people may not be completely aware of that.

Another unrelated problem seldom noted is that for records, the
evaluation order is that of the record definition, not that used when
creating it. And the same thing is true for labelled functions.
So you cannot expect the evaluation order to be exactly the one
appearing in the code.

Cheers,

        Jacques