Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Future of labels
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-04-09 (08:33)
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 <>

> 	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

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

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
  (f 0) : ?b:int -> int -> int
  (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.


Jacques Garrigue
To unsubscribe, mail  Archives: