Re: [Caml-list] Future of labels

[John Max Skaller <skaller@ozemail.com.au>]

Markus Mottl wrote:

> One well-known reason for avoiding fully commuting labels is the problems
> they create with the use of higher-order functions. 

	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.

	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.

	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_.
For example, if you need to make the function 'pi' accepting unit and
returning float a binary function (ignoring both arguments) then
you can use the (classic mode) lambda

	fun x y -> pi ()

as the argument, but it cannot be done by either style of currying.

	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.

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?

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