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

[Frank Atanassow <franka@cs.uu.nl>]

I'm neutral on the future of labels; I'll use Ocaml in whatever form it takes.
But I just want to make some observations.

First, I think there is a tension on a larger scale between:

  * using labels in a library to distinguish arguments of functions with many
    arguments, and

  * refactoring a library to use a combinator-style approach as you often see
    in Haskell programs, for example with parsers, pretty-printers and GUI
    libraries.

Personally, I think the combinator-style libraries are more flexible and
more interesting than the more conventional monolithic approach, but in Ocaml
I feel there is a bias towards more traditional approaches to library
development which makes labels useful in practice.

Also, even when, like me, you prefer the combinator style, interfaces to
foreign programs---which all inevitably adopt the monolithic approach---are
usually arranged in two layers, the lower being a thin layer which just makes
the foreign functions directly available in the Ocaml language, and the upper
being a thick layer which decomposes monolithic operations into combinators,
and for writing the thin layer labels are still clearly a boon.

Second, in practice my biggest complaint about labels is the need to
eta-expand arguments of higher-order functions. I find it truly
annoying. Really. It just feels wrong that I have to relabel a function
argument, even if I'm not passing it any parameters. To me, this suggests that
labels do not belong in the type of a function, and rather that labels should
really only be an elaboration of the function application syntax. (So, instead
of one syntactic construct for application, namely juxtaposition, you have an
infinite number, one for each sequence of labels.) But that is a much more
fundamental issue, and is outside the scope of this discussion...

Lastly, I just have a small syntax suggestion.

Xavier Leroy wrote (on 03-04-01 10:52 +0200):
> (One consequence of this requirement is the ~label:arg syntax, because
> the label:arg syntax of OLabl and OCaml 2.99 was causing syntax
> ambiguities with type constraints ident:type and thus breaking
> backward compatibility.)

Patrick complained about the ~label:arg syntax. I think it is tiresome too. An
alternative is to force labels to be uppercase identifiers and get rid of the
leading tilde. This is not 100% backwards compatible, but I think it only
overlaps with the case where you provide a type constraint for a nullary
data constructor, which is quite uncommon. It also ensures there is no overlap
between keywords and labels, and looks quite suggestive for folds:

  List.foldr xs Cons:(+) Nil:0

Oh yeah, and I do think structural folds should be labeled by the constructors
of the datatype you are deconstructing. It is more meaningful than using
names like ~f: or ~funct:, which does not scale to the general initial
algebra case anyway. I have no suggestion for treating foldl-type things.

-- 
Frank Atanassow, Information & Computing Sciences, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-3261 Fax +31 (030) 251-379
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr