English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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 (03:53)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] Future of labels, and ideas for library labelling
Hi Patrick,

Good to have a contradictory answer, since I was only attacked by more
extremist than myself.
My answer is frontal, but this does not mean that I'm discarding
your arguments. I just express another point-of-view.

> 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'm not really convinced of that. SML for instance has structural
records, and uses them in its basis library. You can look at the result
for yourself. For me it's only half the way.
* You cannot mix labeled and unlabeled arguments, whereas you often
  want to keep one unlabeled argument in your function.
  So you only get a weak form of commutation.
* I believe labels + currying give a nicer syntax. With tupled/record
  arguments it is much less natural to write a function inside a
  functional call.
* You would of course have to extends records with optional fields,
  with creates new problems of overloading.

Another way to see it is to compare Perl/Tk or Python/Tk with Tcl/Tk.
I think Tcl/Tk is nicer, even with all the ugliness of Tcl.

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

So, first let me see what your function is intending to do.
Ah, yes, your lists argument is a list of lists, and you want to put
everything into a set.
Now let's write it with labels
   List.fold_left lists ~init:IntSet.empty
     ~f:(fun set l ->
           List.fold_left l ~init:set ~f:(fun set x -> IntSet.add x set))
Note that I've switched to List.fold_left, which is tail recursive,
but you cannot do it with your approach.
I have also eta-expanded more than necessary, to make the code more
We can write something shorter if we use labels as they were in ocaml
2.99, before their trimming:
   List.fold_left lists ~acc:IntSet.empty
     ~f:(List.fold_left ~f:(fun ~acc item -> IntSet.add acc ~item))
Now, which is the more readable program, this one or yours.

Honestly, using folding functions without labels and eta-expansion is
just a nightmare to decrypt. For me it was really revealing to hear
from program transformation researchers in Haskell (who use fold for
their transformations) that they didn't use it directly in actual

Another problem about fold without labels is that I often use it
with two lists as parameters, and if you pass them in the wrong order
you have a well-typed utterly wrong program.
Can you tell at first sight if this code is correct or not?

List.fold_left (fun l x -> if List.mem x l then l else x::l) [1;2;1] []

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

When composing, you are talking of transformer functions of one
argument. Most of them have no label anyway, so I don't see the
problem. Otherwise you eta-expand. Big deal.

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

My experience, and that of Wolfram Kahl, is that the eta-expansions
you have to do when labels get in the way are more useful than
harmful. Hard to grasp at the beginning, but clearly there is good
verbosity and bad verbosity. Making the labels apparent is generally
good verbosity.

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

Ah, this choice was a result of long, and sometimes tense, discussion
among developpers. I'm not sure we want to have this discussion again.

There are two solutions:
* use the olabl mode with camlp4, and you revert back to ocaml 2.99
  syntax. No need to type the ~ anymore. Neat hack.
* move the ~ on your keyboard to a more accessible place. This came up
  in the discussion, but we concluded that most editors give you ways
  to reassign keys.


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