From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id B4622BC6B for ; Thu, 24 Jan 2008 23:48:15 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADKkmEfUGypAimdsb2JhbACBV45NAQEBCAIIBwoICQeeWQ X-IronPort-AV: E=Sophos;i="4.25,246,1199660400"; d="scan'208";a="21768319" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Jan 2008 23:48:13 +0100 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0OMmEfh027971 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 24 Jan 2008 23:48:15 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADKkmEfUGypAimdsb2JhbACBV45NAQEBCAIIBwoICQeeWQ X-IronPort-AV: E=Sophos;i="4.25,246,1199660400"; d="scan'208";a="21768318" Received: from smtp7-g19.free.fr ([212.27.42.64]) by mail4-smtp-sop.national.inria.fr with ESMTP; 24 Jan 2008 23:48:12 +0100 Received: from smtp7-g19.free.fr (localhost [127.0.0.1]) by smtp7-g19.free.fr (Postfix) with ESMTP id 27DCC32282C; Thu, 24 Jan 2008 23:48:14 +0100 (CET) Received: from macbookpro.local (lns-bzn-48f-81-56-220-129.adsl.proxad.net [81.56.220.129]) by smtp7-g19.free.fr (Postfix) with ESMTP id C9AF3322800; Thu, 24 Jan 2008 23:48:13 +0100 (CET) Message-ID: <479916AC.8040005@univ-savoie.fr> Date: Thu, 24 Jan 2008 23:52:28 +0100 From: Christophe Raffalli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jacques Garrigue , caml-list@inria.fr Subject: Re: [Caml-list] Strange performances References: <9d3ec8300801172339j38bf734dm5b84f951a4342188@mail.gmail.com> <20080118.181206.85503086.garrigue@math.nagoya-u.ac.jp> <4790D9FC.5090108@gmail.com> <20080119.113243.267873825.garrigue@math.nagoya-u.ac.jp> In-Reply-To: <20080119.113243.267873825.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 479915AE.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; christophe:01 raffalli:01 christophe:01 raffalli:01 univ-savoie:01 constructors:01 ocaml:01 ocaml:01 unspecified:01 rounding:01 syntactic:01 caml-list:01 functions:01 functions:01 computation:01 > 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. > > There is already a mixed evaluation order in OCaml : "&&", "||", ";", ... are left to right (and the logical connective are lazy moreover) So left to right everywhere except in function applications would be the simplest deterministic strategy for OCaml ... The current situation with OCaml unspecified evaluation order is really not satisfactory. Let aside that it makes proving code more difficult (more cases to check). But, even if you try to make your code independant from the evaluation order ... how can you be sure ? This would require a random evaluation order to catch your potential bugs. (like the old days Apple's SANE library with a random least significant bit to know how your computation depends on rounding errors, I am missing that one ;-) > 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. > Argh ! Not nice that one ? For what reasons ? Best regards, Christophe