Browse thread
[Caml-list] Future of labels
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jacques Garrigue <garrigue@k...> |
| Subject: | [Caml-list] Indexed and optional arguments (was Future of labels) |
[ This is only remotely related to the original subject ] From: John Max Skaller <skaller@ozemail.com.au> > 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