From: John Max Skaller <skaller@ozemail.com.au>
To: Markus Mottl <mottl@miss.wu-wien.ac.at>
Cc: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>, caml-list@inria.fr
Subject: Re: [Caml-list] Future of labels
Date: Wed, 11 Apr 2001 04:42:27 +1000 [thread overview]
Message-ID: <3AD35413.FBF92146@ozemail.com.au> (raw)
In-Reply-To: <20010409104520.A5091@miss.wu-wien.ac.at>
Markus Mottl wrote:
> 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".
Doesn't this simply suggest that the library author should not
se labels on functions with a small number of obvious arguments?
> But functions can be designed in a way such that positions will usually
> match.
As I understand it, this will still work in commuting labelled
mode by using labels more sparingly when defining functions.
> But I don't care about the benefits of commutation if the label names
> don't match.
This problem is no different from the same problem
applying a functor. The names in the functor signature must match
the argument. If they don't you have to 'remap' them by defining
another module.
> In this case (which is, I fear, the usual one) I'll have
> to write out all arguments and label names _anyhow_.
let f x y = y in
fold_left f x l
works in commuting label mode if fold_left is defined without labels.
On the other hand:
w#set_press (fun ~x ~y ~time ~ctrl ~shift -> ... )
is fine for the set_press GUI function which accepts a callback
with a lot of arguments. Aren't we arguing about how much labelling
to do in a library, rather than whether using the labels _if provided_
should be mandatory?
> 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.
In C++, defaults are given at the _end_ of the parameter list.
In Ocaml, they go at the beginning. This is confusing. :-)
--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr
next prev parent reply other threads:[~2001-04-11 14:02 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-29 0:44 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 ` [Caml-list] Indexed and optional arguments (was Future of labels) Jacques Garrigue
2001-04-10 18:23 ` [Caml-list] " John Max Skaller
2001-04-09 8:45 ` [Caml-list] Future of labels Markus Mottl
2001-04-10 18:42 ` John Max Skaller [this message]
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
2001-03-29 19:56 [Caml-list] Future of labels Manuel Fahndrich
2001-03-30 3:01 ` Jacques Garrigue
2001-03-30 8:23 ` Markus Mottl
2001-03-30 9:45 ` kahl
2001-03-30 10:43 ` Jacques Garrigue
2001-03-30 12:32 ` Benjamin C. Pierce
2001-03-30 10:39 ` Judicael Courant
2001-03-30 10:54 ` Jacques Garrigue
2001-03-30 11:22 ` Francois Pottier
2001-03-30 12:41 ` Benjamin C. Pierce
2001-03-30 14:16 ` Jean-Marc Alliot
2001-03-29 23:47 Arturo Borquez
[not found] <200103300810.AAA05312@mrs.mrs.med.ge.com>
2001-03-30 10:31 ` Jacques Garrigue
2001-03-31 3:40 Yaron M. Minsky
2001-04-11 3:35 G Michael Sawka
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=3AD35413.FBF92146@ozemail.com.au \
--to=skaller@ozemail.com.au \
--cc=caml-list@inria.fr \
--cc=garrigue@kurims.kyoto-u.ac.jp \
--cc=mottl@miss.wu-wien.ac.at \
/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