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 KAA19819; Mon, 9 Apr 2001 10:33:24 +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 KAA21653 for ; Mon, 9 Apr 2001 10:33:23 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f398XLf08651 for ; Mon, 9 Apr 2001 10:33:22 +0200 (MET DST) Received: from localhost (mikan.kurims.kyoto-u.ac.jp [130.54.16.202]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id RAA03054; Mon, 9 Apr 2001 17:33:11 +0900 (JST) To: skaller@ozemail.com.au Cc: caml-list@inria.fr Subject: [Caml-list] Indexed and optional arguments (was Future of labels) In-Reply-To: <3AD11034.E9210A65@ozemail.com.au> References: <20010329094438J.garrigue@kurims.kyoto-u.ac.jp> <20010329114640.A18984@miss.wu-wien.ac.at> <3AD11034.E9210A65@ozemail.com.au> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010409173310F.garrigue@kurims.kyoto-u.ac.jp> Date: Mon, 09 Apr 2001 17:33:10 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [ This is only remotely related to the original subject ] From: John Max Skaller > 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. This is already the case :-) Label-selective lambda-calculus, on which the label mode is based, includes both numerically indexed and labelled arguments, and position arguments follow exactly the sugar you explained above. "The typed polymorphic label-selective lambda-calculus" is a good reference. See http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/. More precisely, (f x y) is equivalent to (f ~1:x ~2:y) (I prefer starting from 1), which is itself equivalent to both ((f ~1:x) ~1:y) and ((f ~2:y) ~1:x). That's all the point of selective lambda-calculus: merging out-of-order partial application and currying. Indexes are not in OCaml, because the rules to compute them in presence of commutation seemed too complex for daily use, but the theory is still integrated: you can view no label as a special label "1", and use the same rules for all arguments. > 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? The rule in OCaml tries to be simple: applying a function containing optional parameters to a non-labeled argument which is abstracted _after_ optional ones causes them to be discarded. If you have a function f : ?a:int -> int -> ?b:int -> int -> int Then (f 0) : ?b:int -> int -> int and (f 0 0) : int So you see that you can discard optional arguments without giving all non-optional arguments. I used types in the above explanation, but you can also explain in a completely untyped way. See "Labeled and optional arguments for Objective Caml" in my publications. Cheers, Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr