Re: [Caml-list] Future of labels

[Markus Mottl <mottl@miss.wu-wien.ac.at>]

On Mon, 09 Apr 2001, John Max Skaller wrote:
> 	I don't think this is quite right. I'd put the general position
> like this: positional arguments are most useful when functions have
> a small number of arguments, since the notation for both definition
> and calling is compact. However, this style does not scale well:
> labelled arguments scale up better, and this _includes_ the case
> of higher order functions.

The difference between label mode and classic mode in this respect (HOFs)
is that in classic mode I can choose in most cases whether I eta-expand
and labelize whereas in label mode I am forced to eta-expand if labels
do not match (and they usually don't!).

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".

> 	I'd like to explain the latter point. If you have a function
> accepting functions, some of which in turn accept functions,
> then your calling syntax is highly sensitive to perturbations
> in the definitions. I'd expect some of the parameters to have types
> such that the argument is a partial application of some other function,
> and given the large number of arguments hypothesis, positional currying
> will rarely
> be enough to reorganise the arguments anyhow. For consistency, one would
> use lambdas like (fun x y -> f a x b y) as arguments everywhere since
> they
> require less work to rewrite.

But functions can be designed in a way such that positions will usually
match. Nobody would define "f" in the way above if it is usually to be
used as a curried HOF.

> 	The big advantage of label mode for higher order functions
> is that label-style currying is more flexible by virtue of commutation,
> and therefore allows a more systematic way of passing arguments
> to higher order functions. The big _disadvantage_ here is that when
> this style of currying is not enough, one must resort to lambdas
> _anyhow_.

But I don't care about the benefits of commutation if the label names
don't match. In this case (which is, I fear, the usual one) I'll have
to write out all arguments and label names _anyhow_.

> 	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 -> ...

This looks messy to me.

> 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?

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.

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr