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 KAA21837; Mon, 9 Apr 2001 10:45:43 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA21924 for ; Mon, 9 Apr 2001 10:45:42 +0200 (MET DST) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f398jgf08963 for ; Mon, 9 Apr 2001 10:45:42 +0200 (MET DST) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id KAA08346; Mon, 9 Apr 2001 10:45:20 +0200 (MET DST) Date: Mon, 9 Apr 2001 10:45:20 +0200 From: Markus Mottl To: John Max Skaller Cc: Jacques Garrigue , caml-list@inria.fr Subject: Re: [Caml-list] Future of labels Message-ID: <20010409104520.A5091@miss.wu-wien.ac.at> References: <20010329094438J.garrigue@kurims.kyoto-u.ac.jp> <20010329114640.A18984@miss.wu-wien.ac.at> <3AD11034.E9210A65@ozemail.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AD11034.E9210A65@ozemail.com.au>; from skaller@ozemail.com.au on Mon, Apr 09, 2001 at 11:28:20 +1000 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 09 Apr 2001, John Max Skaller wrote: > 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. The difference between label mode and classic mode in this respect (HOFs) is that in classic mode I can choose in most cases whether I eta-expand and labelize whereas in label mode I am forced to eta-expand if labels do not match (and they usually don't!). Even if it seems right that labels scale better on functions that have many arguments (especially for ones of same type), we shouldn't neglect the fact that such functions are much, much rarer, both as definition and as application. We should certainly also consider statistical (information theoretic) aspects of the "OCaml-channel" when trying to find an "optimal code". > 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. But functions can be designed in a way such that positions will usually match. Nobody would define "f" in the way above if it is usually to be used as a curried HOF. > 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_. But I don't care about the benefits of commutation if the label names don't match. In this case (which is, I fear, the usual one) I'll have to write out all arguments and label names _anyhow_. > 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 -> ... This looks messy to me. > 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? I don't know whether you are speaking of label mode, which I don't know too well. With classic mode I don't find it so difficult: if I use any non-optional argument that comes after the default arguments, they will be bound to their defaults. Regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr