caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: skaller@ozemail.com.au
Cc: caml-list@inria.fr
Subject: [Caml-list] Indexed and optional arguments (was Future of labels)
Date: Mon, 09 Apr 2001 17:33:10 +0900	[thread overview]
Message-ID: <20010409173310F.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <3AD11034.E9210A65@ozemail.com.au>

[ 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


  reply	other threads:[~2001-04-09  8:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-29  0:44 [Caml-list] Future of labels Jacques Garrigue
     [not found] ` <AAEBJHFJOIPMMIILCEPBEEFHCHAA.mattias.waldau@abc.se>
2001-03-29  6:43   ` Jacques Garrigue
2001-03-29 11:44     ` Mattias Waldau
2001-03-29 17:52     ` Mattias Waldau
2001-03-29  8:22 ` Chris Hecker
2001-03-29  9:46 ` Markus Mottl
2001-04-09  1:28   ` John Max Skaller
2001-04-09  8:33     ` Jacques Garrigue [this message]
2001-04-10 18:23       ` [Caml-list] Re: Indexed and optional arguments (was Future of labels) John Max Skaller
2001-04-09  8:45     ` [Caml-list] Future of labels Markus Mottl
2001-04-10 18:42       ` John Max Skaller
2001-04-10 22:01         ` Markus Mottl
2001-03-29 12:53 ` Judicael Courant
2001-03-30  3:42   ` [Caml-list] Implicit parameters (was Future of labels) Jacques Garrigue
2001-03-30  7:55     ` Markus Mottl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010409173310F.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=skaller@ozemail.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).