Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] Future of labels
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-04-03 (01:53)
From: Patrick M Doane <patrick@w...>
Subject: Re: [Caml-list] Future of labels, and ideas for library labelling
Hi Jacques,

I have worked with both the commuting label mode and classic mode.  My
experience has been that the labels can be useful in some places and not
in others.

I see that labels are useful when working with functions with a large
number of functions or default arguments. This problem can also be solved
nicely when the language supports shared field names among record types.
I think it would be much more useful to fix this problem than to focus on 
labelled arguments. Even better, support light-weight extensible records
with labels as first class values. Then we could build a really good
implementation of a relational algebra.

I also find that labels work very poorly with basic aspects of functional
programming. What is the "right way" to code these examples:

 1.  List.fold_right (List.fold_right IntSet.add) lists IntSet.empty

     How can I use labels here without eta expansion?

 2.  let (<<) f g x =  f (g x)

     What labels should be assumed about f and g?  Without any labels, the
composition operator will not be very useful.

As far as I can tell, the only sensible way for labels to exist in the
language is if they are completely optional.

BTW, if labels are to stay, can we do something about the syntax?  Hitting
the tilde gets really tiring on the hands.


On Tue, 3 Apr 2001, Jacques Garrigue wrote:

> OK, now I have three answers calling for a more radical shift
> toward labels :-)
> Of course labels are the Right Way (yet, I don't care about trade marks).
> Otherwise I wouldn't have suggested to introduce them in ocaml
> in the first place.
> Here is again a long explanation.
> When labels were first introduced in Olabl, about 5 years ago, I did
> not realize it fully: this was just an experiment in how many labels
> you can put in a library, and how it feels to use. But then using it
> myself, and having students use it, I came to realize that
> _compulsory_ labels are really the way to go.  Of course optional
> arguments are very nice for libraries, as everybody seems to agree,
> but compulsory labels on non optional arguments are the real thing,
> which change the programming experience (to speak Self'ish).
> Commutation also matters, but again it is secondary to the fact that
> all uses of a function will be coherently labeled. (By the way all
> this discussion about labels being hard to understand to beginners is
> of course trash. They clearly make understanding easier. But they may
> make the teacher's work harder :-))
> After various attempts at labelling, the conclusion was that you
> should put as many labels as possible, with at most one non-labeled
> argument per function, and very often none at all.
> (By this standard the current labelling of the standard library is
> just broken.)
> Why such a frenzy of labels ? Nothing so surprising: natural language
> is full of grammatical redundancies. You don't ask why you should put
> an article before a name, or why a verb works with a particular
> preposition. That's all defined, and it helps understanding each other.
> Many people believe that since functional programming languages have a
> mathematical basis, they should look like mathematical formulae, but
> this is plain wrong: they should be redundant enough so that you
> understand them as you understand a math course. You would be surprised
> if the professor never reminded you of the meaning of a theorem when
> using it, just because it was proved once!
> So (compulsory) labels are the way to go. But what are labels in
> ocaml? Most people just consider them as an extension, like objects
> are. There are no objects used in the bytecode compiler, so there
> should be no labels there, and as a result no (compulsory) labels in
> the standard library.
> Considering the history of Caml, this seems hard to refute.
> The only new feature that made its way to the core is modules, and
> the name changed from caml-light to caml special light then.
> So if labels are to have the same role, people would expect a change
> in the name of the language itself. I'm not sure this is really what
> is needed now. (Wolfram talked about the freedom to stay with an older
> version: this is exactly what happened for the many people who went on
> using caml-light until recently)
> Another example is Haskell: type classes became the main feature of
> this language, so omnipresent that even the map function is
> overloaded. A lot of comfort was gained, but the simplicity of the
> core language was lost.
> That was basically the dillemma when merging olabl into ocaml: olabl
> was a different language, and I cannot see how all ocaml users could
> suddenly be convinced to switch to olabl.
> That's why I'm trying to make proposals that do not touch too directly
> the core of the language. Just to make it easy to everybody.
> I'm not sure I'm sacrificing the right way. What was the right way for
> olabl is not necessarily the right way for ocaml. Yet, I would not
> like to see labels limited to a small set of libraries, like LablTk
> and LablGTK.
> Also, these reactions surprised me a bit. I can very well see why
> Wolfram pushes labels: he has as much experience as me in them, and
> knows where they help. But Judicael and Markus had just said that they
> were not using label mode. They may convince people much better if
> they come back next week after having converted a few programs to
> labels mode :-) Seriously, what labels lack currently is serious
> users. (Well, there are some in Japan, but they are not very
> outspoken).
> Best regards,
> Jacques Garrigue
> -------------------
> To unsubscribe, mail  Archives:

To unsubscribe, mail  Archives: