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 TAA00834; Thu, 5 Apr 2001 19:42:59 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA00901 for caml-list@pauillac.inria.fr; Thu, 5 Apr 2001 19:42:58 +0200 (MET DST) 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 WAA19510 for ; Wed, 4 Apr 2001 22:37:50 +0200 (MET DST) Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f34KbnH09733 for ; Wed, 4 Apr 2001 22:37:50 +0200 (MET DST) Received: from [195.20.224.204] (helo=mrvdom00.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 14ku2E-0000z0-00; Wed, 4 Apr 2001 22:37:46 +0200 Received: from drms-3e35781a.pool.mediaways.net ([62.53.120.26] helo=ice.gerd-stolpmann.de) by mrvdom00.schlund.de with esmtp (Exim 2.12 #2) id 14ku28-0001hn-00; Wed, 4 Apr 2001 22:37:41 +0200 Received: from localhost (localhost [[UNIX: localhost]]) by ice.gerd-stolpmann.de (8.9.3/8.9.3) id WAA31127; Wed, 4 Apr 2001 22:37:11 +0200 From: Gerd Stolpmann Reply-To: gerd@gerd-stolpmann.de Organization: privat To: Jacques Garrigue , Jean-Christophe.Filliatre@lri.fr, orodeh@cs.huji.ac.il Subject: Re: [Caml-list] Future of labels, and ideas for library labelling Date: Wed, 4 Apr 2001 21:18:18 +0200 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: caml-list@inria.fr References: <20010403105212.A15700@pauillac.inria.fr> <15049.51482.197252.672850@pc803> <20010403230626W.garrigue@kurims.kyoto-u.ac.jp> In-Reply-To: <20010403230626W.garrigue@kurims.kyoto-u.ac.jp> MIME-Version: 1.0 Message-Id: <01040422370105.00489@ice> Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Tue, 03 Apr 2001, Jacques Garrigue wrote: >Last message before I make a needed pause, since I think lots of >people are already discarding this thread anyway. As I saw that many messages, I skipped the thread first. But I know it's important... Sometimes it is better to wait until the direction of the discussion becomes clearer. I must admit that I never _decided_ whether to use classic mode or label mode; I had my code base, and when O'Caml 3 was introduced I took the simplest way to maintain my code. That was classic mode, because labels mode was incompatible to previous versions of O'Caml. I began to use optional arguments, and from time to time I also assigned labels to non-optional arguments. Even more seldom I wrote labels at applications. (I _am_ an incremental learner.) So I am a 50% classic mode user. 50% because I think labels are useful in signatures (as documentation), but I can live without labels in implementations. In my opinion, a (non-optional) "labels are comments in signatures" mode would be right (i.e. nolabel mode). However, there is an argument against this type of nolabel mode. As a "library provider" I see the following problem with such a mode (and with the current classic mode, too): I'm sometimes assigning too many labels, as in: val f : ?optional:s -> nonoptional:t -> u This is very natural if your main intention is documentation. But: In classic and nolabels mode, the ~optional argument is really optional because you don't apply the ~nonoptional argument with a label. But in labels mode, you must pass the optional argument in order to execute the function. Okay, the compiler prints warnings in such cases, but as a classic/nolabel user I can ignore them. So I fear that libraries provided by users such me tend to have pitfalls for labels users. Because of this, I suggest that the compiler enforces that non-optional labels are either turned on or off: If the .ml file is compiled with labels turned off, the .mli file must not contain labels. If the .ml file is compiled in label mode, it is accepted that the .mli file contains labels. So I am no longer allowed to mix labeled declarations/definitions and unlabeled applications in an insane manner. Note that it is still possible to _use_ a labeled library in nolabel mode; in this case all the labels are ignored. >I just repeat here what was my last proposal, since it was in the >middle of a mail, and some interested people may have not read it. >At least, they don't seem to have read it. >(It's only a personal idea.) > >* make label mode the default mode Which mode is the default is very important. Users tend to keep the default mode; so this mode will be used more frequent than the other mode. However, I think we should not discuss about this point politically (i.e. who wins the default mode wins the battle). Only a remark... >* keep a nolabel mode similar to current classic mode, but not > allowing non-optional labels in function calls As I already explained, I suggest to disallow non-optional labels in abstractions and in signatures, too. This ensures that a library written in any of both modes can be used in programs using the other mode in a sane way. >* remove all labels from the standard library The standard library can remain labeled, because a nolabel user sees a view of the standard library where all non-optional labels are stripped. But the stdlib must itself be written in label mode. >* introduce a module StdLabels containing labelized versions of List > and Array for labellers >* add some extra labelized versions of a few functions: > Pervasives.output', Pervasives.input', Pervasives.really_input', > Array.blit', String.blit' > and maybe also String.sub', String.fill', Buffer.add_substring', > Hashtbl.add', Map.add'. This looks very ugly. >Remark that this does not change anything for people who didn't use >labels before: label mode is a conservative extension of ocaml 2, so >you don't even need to use the nolabel mode. Fully agreed. To summarize my suggestion: - Two modes as before, but with clear roles: - nolabels mode: Non-optional labels are totally forbidden. Neither abstractions nor applications nor mli files must contain labels. Optional labels are possible. When calling a library written in label mode, the arguments are identified by position nevertheless. - labels mode: Can remain as it is. - Standard library: Is written in label mode, and has a labeled signature. - Default mode: Is the nolabels mode because this mode is backward-compatible to O'Caml 2 and all 0% classic mode users (those who never use labels in their own abstractions nor in applications) I think most current classic mode users can live with this. The difference between these nolabels and labels modes is bigger than in the current version of the language, as both modes emphasize their view on argument handling. This may motivate people to switch from nolabels to labels mode, because there is a real benefit from it. (You get the labels only if you switch, even if your motivation for labels is code documentation and not the possibility of commutation.) A last thought: The nolabels mode should be called positional mode; "nolabels" sounds very negative and one may associate with this name that its support will end in the near future. (I also thought about a better name for label mode because many people on the list were confused from the fact that it only changes the meaning of non-optional labels. "Commuting non-optional labels mode" is too long. But renaming the classical mode has an impact on that, too.) Gerd -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 100 64293 Darmstadt EMail: gerd@gerd-stolpmann.de Germany ---------------------------------------------------------------------------- ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr