Re: [Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

The situation seems to have calmed down a bit. Or is it just that
there is another more active thread?

Anyway, I think that the conclusion is not very far. At least, we have
collected all known problems about labels, and tried to answer them.

Here is a summary of the plan I tried to draw from many people's
contributions (and my own experience and convictions :-)):

* remove labels from standard libraries
* make label mode the default (and practically unique) mode;
  this preserves compatibility with ocaml 2.x
* slightly extend it to allow non-labelled complete applications of
  functions: this is non-ambiguous, but keep a warning for purists,
  and also because of the slight mismatch between program text and
  untyped semantics
* put some labels in alternative versions of a few libraries
  (List, Array, Unix). Access to these libraries would use already
  existing ways: "open Stdlabels", "module Unix = Lunix"
* also add alternative labelled versions for the few functions with
  more than 4 arguments in the standard library (e.g. String.blit')

I didn't get explicit support for the last addition: allow some
non-labeled applications. Is it useful for some people, or should
we avoid it for the gap in the semantics?

If you're happy with all that, silent consent is enough.
If you think this still misses the point, or something could be
improved, explain yourself, but please do not make proposals: there is
a very high probability that they are going to be flawed at either the
typing or semantics level, and this is very hard to integrate them in
the vision.


Here are some very short answers to many suggestions. Sorry if I
forgot some.

To Claude Marche:
> Could it be interesting that have such an option,
> i.e. allowing at most one non labelled argument ?
I think this is the right way to label most functions. But you cannot
enforce that, because of currying. Also, in some cases the
non-labelled argument is split in two related arguments (something like
base and offset), so you don't need to be too strict on the form. The
idea matters.

To John Skaller:
> Doesn't this simply suggest that the library author should not
> put labels on functions with a small number of obvious arguments?
(S)he is free to do that. But I wouldn't support this idea; this lacks
coherence, and is not really needed. Most higher-order functions do
take functions of only one argument, and in most cases this argument
happens (and not by chance) to be the one left unlabelled in the
function type. The experience is that in most cases eta-expansion is
not even needed. In fact labels may even avoid it, since the
unlabelled argument is not always the last one.

To Brian Rogoff:
> I know you'll hate this, but what about insisting on an explicit type for 
> functions which use commuting labels? Could something like that be made to
> work?
No hate involved here. This is exactly what the example with subtyping
demonstrated in my previous mail: this cannot be made to work without
badly breaking the semantics. Classic mode and commutation (even with
explicit types) are fundamentally incompatible.
Also, I didn't really see any strong support for labels in classic
mode: labels without commutation are not so much fun.

To Michael Sawka:
> Unless I am missing something, I don't see how you can reconcile
> normal function application with commuting labeled arguments within
> the current type system.
Thank you for joining the discussion, but this is really what label
mode is about, and it just happens to work, and be relatively simple
(when you don't mix with optional arguments). What you have is a
conservative extension of lamba-calculus (using the default empty
label), where you can also pass arguments on a different label, all
this compiled to plain lambda code for a 0-cost execution model.


Cheers everybody,

       Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr