caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: patrick@watson.org
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Future of labels, and ideas for library labelling
Date: Tue, 03 Apr 2001 12:53:14 +0900	[thread overview]
Message-ID: <20010403125314Q.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <Pine.BSF.3.96.1010402211922.97906A-100000@fledge.watson.org>

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

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.

Cheers,

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


  reply	other threads:[~2001-04-03  3:53 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-31  3:40 [Caml-list] Future of labels Yaron M. Minsky
2001-04-02  3:39 ` [Caml-list] Future of labels, and ideas for library labelling Jacques Garrigue
2001-04-02  7:58   ` Judicael Courant
2001-04-02  8:50     ` Markus Mottl
2001-04-02 10:33     ` kahl
2001-04-03  0:35       ` Jacques Garrigue
2001-04-03  1:36         ` Kipton M Barros
2001-04-03  1:52         ` Patrick M Doane
2001-04-03  3:53           ` Jacques Garrigue [this message]
2001-04-03  5:10             ` Patrick M Doane
2001-04-03  9:30               ` Jacques Garrigue
2001-04-03  8:52             ` Xavier Leroy
2001-04-03  9:34               ` Judicael Courant
2001-04-03  9:54               ` Jacques Garrigue
2001-04-03 12:59                 ` Jean-Christophe Filliatre
2001-04-03 13:11                   ` [Caml-list] ocaml, java, rmi and jini Martin Berger
2001-04-03 19:23                     ` Chris Hecker
2001-04-03 20:50                       ` Gerd Stolpmann
2001-04-06  9:40                         ` Sven LUTHER
2001-04-06 20:57                           ` Gerd Stolpmann
2001-04-03 21:06                       ` martinb
2001-04-06 15:03                     ` Xavier Leroy
2001-04-03 14:06                   ` [Caml-list] Future of labels, and ideas for library labelling Jacques Garrigue
2001-04-03 14:12                     ` Daniel de Rauglaudre
2001-04-03 14:42                       ` Claude Marche
2001-04-04 19:18                     ` Gerd Stolpmann
2001-04-03  9:55               ` Ohad Rodeh
2001-04-03 18:06                 ` [Caml-list] Example of Ocaml-syntax problem with ; Mattias Waldau
2001-04-04 15:15                 ` [Caml-list] Suspending threads Ohad Rodeh
2001-04-04 17:28                   ` Vitaly Lugovsky
2001-04-06 13:21                   ` Xavier Leroy
2001-04-03 12:02               ` [Caml-list] Future of labels, and ideas for library labelling Dave Mason
2001-04-03 13:43               ` Francois-Rene Rideau
2001-04-03 14:23                 ` Daniel de Rauglaudre
2001-04-03 13:43               ` Frank Atanassow
2001-04-03 13:58               ` Joshua D. Guttman
2001-04-03 16:52               ` Eric C. Cooper
2001-04-09  9:05                 ` John Max Skaller
2001-04-09  7:29             ` John Max Skaller
2001-04-03  8:07         ` Judicael Courant
2001-04-03  6:55     ` Chris Hecker
2001-04-03 18:13       ` [Caml-list] Generics? Brian Rogoff
2001-04-03 20:12         ` Chris Hecker
2001-04-10 16:48           ` John Max Skaller
2001-04-09  8:11       ` [Caml-list] Future of labels, and ideas for library labelling John Max Skaller
2001-04-09  9:21         ` Jacques Garrigue
2001-04-09 15:06           ` Fergus Henderson
2001-04-10 18:49           ` John Max Skaller
2001-04-09 19:54         ` Chris Hecker
2001-04-10  3:37           ` Jacques Garrigue
2001-04-10  7:42             ` Judicael Courant
2001-04-10  8:25               ` Jacques Garrigue
2001-04-10  8:46               ` Claude Marche
2001-04-10 10:09                 ` Jacques Garrigue
2001-04-10 14:42                   ` Lionnel Maugis
2001-04-10  9:06             ` François-René Rideau
2001-04-11 15:34               ` Jacques Garrigue
2001-04-11 17:48                 ` Dave Mason
2001-04-12 12:39                 ` [Caml-list] How do I define prog1? Mattias Waldau
2001-04-12 14:22                   ` Vitaly Lugovsky
2001-04-12 17:53                     ` William Chesters
2001-04-12 15:15                   ` Sven LUTHER
2001-04-12 16:14                     ` Mattias Waldau
2001-04-12 15:21                   ` Maxence Guesdon
2001-04-12 15:47                   ` Stefan Monnier
2001-04-17 20:04                     ` Chris Hecker
2001-04-10 22:43             ` [Caml-list] Future of labels, and ideas for library labelling Brian Rogoff
2001-04-11  8:29               ` Jacques Garrigue
2001-04-11  9:44                 ` Anton Moscal
2001-04-11 13:16                 ` Didier Remy
2001-04-11 15:11                   ` Jacques Garrigue
2001-04-03  7:27 Arturo Borquez
2001-04-03 16:39 John R Harrison
2001-04-04 16:37 Dave Berry
2001-04-11 10:48 Francois-Rene Rideau
2001-04-17 11:53 Poigné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010403125314Q.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=patrick@watson.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).