From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA04138 for caml-redistribution@pauillac.inria.fr; Sat, 18 Mar 2000 18:49:05 +0100 (MET) Resent-Message-Id: <200003181749.SAA04138@pauillac.inria.fr> Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA16725 for ; Fri, 17 Mar 2000 20:24:24 +0100 (MET) Received: from isil.localdomain ([192.70.254.187]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id UAA24717 for ; Fri, 17 Mar 2000 20:24:23 +0100 (MET) Received: by isil.localdomain (Postfix, from userid 1000) id 16422369FA; Fri, 17 Mar 2000 14:24:36 -0500 (EST) Sender: prevost@isil.localdomain To: Don Syme Cc: "'Jacques Garrigue'" , "'caml-list@inria.fr'" Subject: Re: Syntax for label, NEW PROPOSAL References: <39ADCF833E74D111A2D700805F1951EF18014511@RED-MSG-06> From: John Prevost Date: 17 Mar 2000 14:24:35 -0500 In-Reply-To: Don Syme's message of "Fri, 17 Mar 2000 09:03:56 -0800" Message-ID: <87bt4dqu18.fsf@isil.localdomain> User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-From: weis@pauillac.inria.fr Resent-Date: Sat, 18 Mar 2000 18:49:05 +0100 Resent-To: caml-redistribution@pauillac.inria.fr Don Syme writes: > o To ensure "living happily together", my feeling is you should > leave the standard library alone (though I could live with 2 or 3 > functions having labels), but go wild with labels and variants in > the places were no one doubts they will be useful. I think I agree here. I do see labels as useful in a number of places (certainly places like Tk where you have large numbers of arguments, many of which are optional.) But, in places in the standard library, you can create some big nasty messes. The List.fold_right example is a good one. On the one hand, I do have to think about which way the folding is going to happen, and which argument to the f argument is which. On the other, there are very few places where a function which is useful for folding has an acc argument. Arguing that a consistent labelling style is good is a nice point. If every function that uses an argument in a certain way has the same label, it makes it easier to remember what's going on. But the functions which need labels most (those which have many arguments) have the most specialized labels. And the functions which are most standard have little ambiguity, leaving reordering of arguments the only benefit: let foo l = map l fun:function ... ... ... I like the ability to move the "heaviest" clause of my expression to the end, but I'm not willing to put up with the acc thing in fold_right to get it. And of course, reordering is only available in "modern" mode. If we could come up with a semantics where labels are always optional, I think I would accept things like acc in the standard library. But when you have to make a choice between optional labels and no useful functionality, it's a harder sell. I can imagine a system in which an unlabelled argument means "the next argument in the argument list, regardless of label" and a labelled argument means "the next argument in the argument list with this label". Of course, this leads to oddness. Let's look at map for a simple example: map : f:('a -> 'b) -> 'a list -> 'b list (I assume this hasn't changed. I'm using f instead of fun.) map x : 'a list -> 'b list map f:x : 'a list -> 'b list without a label for the 'a list, there's no way in this optional-label scheme to re-order the argument earlier. So this would seem to imply that labels would only be useful if there were many different labels, or if unlabelled arguments were "first": map2 : 'a list -> f:('a -> 'b) -> 'b list this option is irritating because it changes the default ordering. And the standard ordering makes a lot more sense, even when you can write: map2 fun:f to get the old behavior. map3 : f:('a -> 'b) -> list:('a list) -> 'b list this option preserves the standard ordering, but we had to define a label for the second argument. That's more okay than it would be in a system where labels are mandatory, but it means more work for people writing libraries using labels. The now need to think about a "standard" ordering for the arguments, as well as a "labelling" which allows reordering. Summary: The standard library should not have labels unless labels undergo a massive change in semantics which will remove the known-ness of labels' utility in O'Labl. I want labels for working with things like LablTk and LablGtk. But when it comes to the standard library, I agree with the SML people. "Gross!" I use O'Caml because it has a nicer, cleaner syntax than SML. Mucking it up like this, even as an optional mode, is bad. John.