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