From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 5D2B6BDCE for ; Tue, 23 Aug 2005 21:52:04 +0200 (CEST) Received: from mallaury.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j7NJq4qh002181 for ; Tue, 23 Aug 2005 21:52:04 +0200 Received: from [192.168.0.3] (planar.net0.nerim.net [213.41.168.102]) by mallaury.nerim.net (Postfix) with ESMTP id 62B834F3B0 for ; Tue, 23 Aug 2005 21:51:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: References: <43065B83.6050503@dravanet.hu> <254E6767-A097-455B-872B-483725D26744@inria.fr> <1124781154.8832.12.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <60195F78-1413-4E10-BAE8-512C76EF8E43@inria.fr> Content-Transfer-Encoding: quoted-printable From: Damien Doligez Subject: Re: [Caml-list] Parameter evaluation order Date: Tue, 23 Aug 2005 21:52:03 +0200 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.733) X-Miltered: at nez-perce with ID 430B7E64.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; damien:01 damien:01 caml-list:01 heap:01 compiler:01 curried:01 higher-order:01 compilation:01 2005,:98 wrote:01 doligez:01 doligez:01 compile:01 functions:01 functions:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Aug 23, 2005, at 15:34, Igor Pechtchanski wrote: > This may be a na=EFve question, but what's wrong with tuples? It =20 > doesn't > seem like the order in which the tuple components are evaluated =20 > matters > (in terms of efficiency, that is). Am I missing something? Tuples, like currying, is only an encoding. If you cannot distinguish between a 4-argument function and a function that takes a 4-tuple as argument, you have to allocate the tuple in the heap instead of passing the 4 arguments directly in registers. Inefficient. Or you have to make your compiler guess which is which, compile some functions as taking 4 arguments and some as taking a tuple, and =20 translate between the two representations as needed, in a way that is very similar to what happens with curried functions, except that this time guessing "n-ary" every time is not quite as good a heuristic. Higher-order functions are particularly good at exposing this problem, because you only know the type of their functional arguments, and you have to deduce the calling convention from no more information than the type itself. But the problem also appears with separate compilation. -- Damien