From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA00878 for caml-redistribution@pauillac.inria.fr; Tue, 21 Mar 2000 15:22:27 +0100 (MET) Resent-Message-Id: <200003211422.PAA00878@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 DAA16708 for ; Sun, 19 Mar 2000 03:27:11 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id DAA05122; Sun, 19 Mar 2000 03:26:46 +0100 (MET) Received: from tet.kurims.kyoto-u.ac.jp (isdnppp2.kurims.kyoto-u.ac.jp [130.54.16.103]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id LAA11529; Sun, 19 Mar 2000 11:26:33 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by tet.kurims.kyoto-u.ac.jp (8.9.3/8.9.3) with ESMTP id LAA32418; Sun, 19 Mar 2000 11:29:13 +0900 (JST) (envelope-from garrigue@kurims.kyoto-u.ac.jp) To: Christophe.Raffalli@univ-savoie.fr, Don Syme , John Prevost , Damien Doligez Cc: Xavier.leroy@inria.fr, caml-list@inria.fr Subject: Re: Syntax for label, NEW SOLUTION In-Reply-To: Your message of "Sat, 18 Mar 2000 11:32:49 +0100" <38D35B51.8EB15DA0@univ-savoie.fr> References: <38D35B51.8EB15DA0@univ-savoie.fr> X-Mailer: Mew version 1.93 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000319112913P.garrigue@kurims.kyoto-u.ac.jp> Date: Sun, 19 Mar 2000 11:29:13 +0900 From: Jacques Garrigue X-Dispatcher: imput version 980905(IM100) Resent-From: weis@pauillac.inria.fr Resent-Date: Tue, 21 Mar 2000 15:22:27 +0100 Resent-To: caml-redistribution@pauillac.inria.fr Since I do not want to flood the caml-list with messages, I answer several messages together. This makes the answer a bit long, but bear with me if you are interested. From: Christophe Raffalli > First to clarify, there are two distinct problems with labels: > > - Their syntax: Anything that let me put (or not put) spaces where I > want will suit me. (If people are not happy with the final syntax let > them use camlp4 :-) That's not easy, but maybe we can find something. After your idea of keeping `:' in types, and only change the syntax for terms, I first thought that this would be bad, in particular this would cause technical problems in the lexer, since we do not want a special lexing rule for `:' anymore. However if we decide that labels cannot have keyword names, this should be possible to work it out at the parser level (the :label form is no longer needed). As Xavier included `\' in his list (which surprised me a little, since for me '\' was taboo), I would go for it. That is, replace ':' by '\' in terms, but keep ':' in types. Any counter-proposals? > - Their semantics in modern mode. > > I quite agree, their should not be two modes, because this will means > two communities of users and therefore at some point two standards > libraries because each kind of users will have different needs. This is > dangerous ... > soon there would not be only one big caml community anymore. There is a misunderstanding here. There are currently two communities, and one goal of the merger is to have a big caml community again. I think that having two modes is a good way to reach this goal. All this discussion just shows that this would be very difficult with only one mode. > But there may be a solution in three step: > > 1) Let's have only the modern mode. But let it accept any expressions > with no amibiguities. This means that if according to both types AND > labels there is a unique valid order of arguments then the compiler do > not complain. > > At this point you can use blit with > > > Array.blit a src_pos:x b dst_pos:y len > > If both array a and b have not the same types and > > > Array.blit src:a src_pos:x b dst_pos:y len > > If they have the same type. > > This is reasonnable ! I do not understand very well your proposal. If you let arguments commute when there is no ambiguity, then this is just a big mess, because the concept of no ambiguity is only understood by the compiler. If you do not let them commute, then I do not see how this improves on classic mode, which already allows you to check labels when you want. > 3) For the problem of List.fold_left (+), there is a solution: tell to > the compiler that (+) is commutative ! Or more generally find a syntax > to tell that two or more arguments of the same types may be commuted > without changing the behaviour of the function. Then there would be no > ambiguities when you type List.fold_left (+) and the compiler wii not > complain ! There would be a problem only with List.fold_left (/) but > then writing the labels explicitely may be better (or rewrite it with a > product). Woa. Teaching properties of functions to the compiler would be very nice, but I'm afraid type checking technology is not nearly mature enough for that. That's a good subject for research :-) From: Don Syme > I really don't see people clamouring for lots of labels in the standard > library (besides the inventors of the language feature, who don't really > count, for lots of obvious reasons - over exposure to the feature, over > familiarity with the label names, a natural bent to program in a particular > way that led them to the feature in the first place, self-selection as > people who think the feature is the best thing ever). Maybe they're just decent, and do not like flame wars. I do not like either, and have to force myself to write these messages. I can only tell you that ocaml-2.99 has a few labels less that olabl, and that I already had comments from olabl users who thought it was "odd". There were also several messages in this forum insisting for then fun: label on functionals, and this is the function fold_right which started all this discussion. > o The fact that you've had to resort to "modes" at all indicates something > is wrong. The point about O'Caml is that you shouldn't have to understand > _anything_ about labels, objects, modules or syntax modes to use the system > as a new user. You shouldn't have to see any labels, nor have to ask "what > are these two modes all about", nor have to try to understand why some of > the arguments have labels and some don't. Well, before that there were two compilers. I think this is a progress. > o The "just documentation" response doesn't really hold water, because if > the labels were just documentation, then they would different. For example, > "fun", being a keyword, is highly confusing and not terribly descriptive - > any sensible prototype would probably just use "f". And C prototypes look > _horrible_ when you have both higher order arguments and argument names. If you think that some labels are not that good as documentation, then make suggestions. Since most people will only use them as doumentation, this should be a priority. And if they are good documentation, then will certainly be good to use in programs also. The problem about C prototypes and higher-order functions is really a problem with the way you write function types in C, not about the variable names. From: John Prevost > 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. Some people really want to eat the cake and still have it. I already explained a while ago why it was not possible to have labels both optionals and commuting in a curried language. Even if it were possible, I would fully agree with Pierre on this point: this is going to make programs unreadable. If you do not decide clearly which is your policy, then you end up with Perl! Do not confuse the fact of having two reasonably consitent modes with having only one in which any strange thing is allowed. From: Damien Doligez > I agree, and I would even go further. I think the current labeling of > the standard library is way too verbose. "fun" should not be "func" > or even "fn", but simply "f". That's the usual name for a generic > function. Likewise, we should replace char:char with c:char and so > on (maybe even the predicate function in List.for_all should be > labeled f). > > Also, in the List module, I found this: > > val nth : 'a list -> pos:int -> 'a > > This is really bad design, unless the goal is to confuse the reader > (two different names for the same number). It should be either > > val nth : 'a list -> n:int -> 'a > > or > > val posth : 'a list -> pos:int -> 'a > . > > I think we need to develop a systematic set of abbreviations (and a > document to explain it) that will allow us to limit almost all labels > to be at most one character in length. It would (at least partially) > solve the problem of expression cluttering that we have with the long > labels currently in the library. As a side-effect, it would also > solve the problem of keywords as labels: there isn't any keyword of > length 1. That sounds reasonable. I would also personally prefer "f:" to "fn:". My choice of labels has been driven by voices from olabl users who insisted that labels should be as readable as possible, but having short names is ok if they are readable. Still I would not support reducing _all_ labels to 1 character, while it might be ok for most of them in the standard library. Having a document for it is only bearable as long as it is standard The choice of pos: rather than n: in List.nth was driven by an attempt at homogeneizing labels with other modules, in which pos: is used. But too much homogeneity is not always good. If the meaning does not exactly match, then it might be better to use another label. Remark that if we are going to do such extensive changes, we must have a coordination to choose labels, and that it will take some time. > This is an excellent suggestion, and I have implemented it (as of > version 2.99+12) : I replaced the command-line option "-modern" with > "-label". I kept "-modern" as an alias to "-label" for the time > being, but I certainly hope we'll retire it before we release 3.00. You're a bit fast Damien. Personally I would really prefer -commute. Labels are also available in classic mode, it is just that they do not commute there. Also a very personal comment: why do you persist in erasing the date from the version number? I really think it helps to trace back problems :-) Best regards to everybody, Jacques --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp JG