From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA01287; Mon, 9 Apr 2001 17:12:16 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA01281 for caml-list@pauillac.inria.fr; Mon, 9 Apr 2001 17:12:15 +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 DAA16023 for ; Mon, 9 Apr 2001 03:30:36 +0200 (MET DST) Received: from localhost.localdomain (ppp41.dyn147.pacific.net.au [210.23.147.41]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f391UUD29971 for ; Mon, 9 Apr 2001 03:30:31 +0200 (MET DST) Received: from ozemail.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id LAA32414; Mon, 9 Apr 2001 11:28:21 +1000 Message-ID: <3AD11034.E9210A65@ozemail.com.au> Date: Mon, 09 Apr 2001 11:28:20 +1000 From: John Max Skaller X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Markus Mottl CC: Jacques Garrigue , caml-list@inria.fr Subject: Re: [Caml-list] Future of labels References: <20010329094438J.garrigue@kurims.kyoto-u.ac.jp> <20010329114640.A18984@miss.wu-wien.ac.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Markus Mottl wrote: > One well-known reason for avoiding fully commuting labels is the problems > they create with the use of higher-order functions. I don't think this is quite right. I'd put the general position like this: positional arguments are most useful when functions have a small number of arguments, since the notation for both definition and calling is compact. However, this style does not scale well: labelled arguments scale up better, and this _includes_ the case of higher order functions. I'd like to explain the latter point. If you have a function accepting functions, some of which in turn accept functions, then your calling syntax is highly sensitive to perturbations in the definitions. I'd expect some of the parameters to have types such that the argument is a partial application of some other function, and given the large number of arguments hypothesis, positional currying will rarely be enough to reorganise the arguments anyhow. For consistency, one would use lambdas like (fun x y -> f a x b y) as arguments everywhere since they require less work to rewrite. The big advantage of label mode for higher order functions is that label-style currying is more flexible by virtue of commutation, and therefore allows a more systematic way of passing arguments to higher order functions. The big _disadvantage_ here is that when this style of currying is not enough, one must resort to lambdas _anyhow_. For example, if you need to make the function 'pi' accepting unit and returning float a binary function (ignoring both arguments) then you can use the (classic mode) lambda fun x y -> pi () as the argument, but it cannot be done by either style of currying. Ideally, we'd like to have label mode, with some support for positional arguments by syntactic sugar (so there is only one mode and one explanation of the fundamental paradigm). For example: fun x y -> ... becomes fun ~0:x ~1:y -> ... that is, we use integers as the labels for a positional definition, and in the call: f x y we add integer labels to the unlabelled arguments by position: f ~0:x ~1:y In this way, we have only strict commuting label mode, but we can still use positional notation via sugar. BTW: the thing I find hardest to wrap my brain around is default arguments. I don't understand how to tell the difference between a partial application which doen't bind defaults and a complete application that does: it seems to be sensitive to whether all the non-default arguments are given or not, which seems fragile. Also, it doesn't seem possible in a partial application to bind a default argument to its default. This seems messy. Am I missing some simple explanation here? -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr