From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id FAA12003; Tue, 3 Apr 2001 05:53:26 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA12001 for ; Tue, 3 Apr 2001 05:53:25 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f333rLf22617 for ; Tue, 3 Apr 2001 05:53:22 +0200 (MET DST) Received: from localhost (mikan.kurims.kyoto-u.ac.jp [130.54.16.202]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id MAA26990; Tue, 3 Apr 2001 12:53:14 +0900 (JST) To: patrick@watson.org Cc: caml-list@inria.fr Subject: Re: [Caml-list] Future of labels, and ideas for library labelling In-Reply-To: References: <20010403093527G.garrigue@kurims.kyoto-u.ac.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010403125314Q.garrigue@kurims.kyoto-u.ac.jp> Date: Tue, 03 Apr 2001 12:53:14 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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