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 KAA16762; Tue, 3 Apr 2001 10:52:21 +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 KAA16807 for ; Tue, 3 Apr 2001 10:52:20 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f338qCf00920; Tue, 3 Apr 2001 10:52:12 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA16795; Tue, 3 Apr 2001 10:52:12 +0200 (MET DST) Date: Tue, 3 Apr 2001 10:52:12 +0200 From: Xavier Leroy To: Jacques Garrigue Cc: caml-list@inria.fr Subject: Re: [Caml-list] Future of labels, and ideas for library labelling Message-ID: <20010403105212.A15700@pauillac.inria.fr> References: <20010403093527G.garrigue@kurims.kyoto-u.ac.jp> <20010403125314Q.garrigue@kurims.kyoto-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010403125314Q.garrigue@kurims.kyoto-u.ac.jp>; from garrigue@kurims.kyoto-u.ac.jp on Tue, Apr 03, 2001 at 12:53:14PM +0900 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Wow, what a lively discussion! I waited for a while before jumping in, to see as many opinions as possible, but actually the arguments put forward are pretty much the same Jacques and the rest of us discussed while designing the OLabl/OCaml merger that gave OCaml 3.00. So, let me recapitulate the ideas behind this design (at least as I remember them). 1- We wanted labeled and optional function arguments to be an extension of the Caml language (just like objects, classes, and modules to a very large extent), i.e. something that does not affect the core ML language, and remain backward compatible with earlier versions of OCaml. I think this is crucial for two reasons. First, it must be possible to learn and teach OCaml incrementally, by successive layers of increasing complexity. Second, we happen to have users that develop significant applications in OCaml, and changing the language in incompatible ways every other year is a sure way to piss them off. We get enough criticism and suspicion about OCaml "changing all the time"... (One consequence of this requirement is the ~label:arg syntax, because the label:arg syntax of OLabl and OCaml 2.99 was causing syntax ambiguities with type constraints ident:type and thus breaking backward compatibility.) 2- With the strict label semantics of OLabl or OCaml with the -labels option (if a label is given in the function definition/declaration, it must be used in all applications of that function), the only way to achieve backward compatibility (point 1 above) is to have versions of the standard libraries that are totally unlabeled. Otherwise, long-time Caml users would have to change every call to List.map in their code, and teachers would have to teach labels very early. Of course, having standard libraries completely unlabeled kind of defeats the purpose of labels (i.e. self-documentation of library functions and additional safety and flexibility at applications of these functions), so Jacques' initial proposal was to have two versions of the standard libraries, one with labels and one without. But we quickly realized this was unfeasible. It's just too hard to maintain two versions of the same libraries. And everyone who writes a Caml library and wants it to be used as widely as possible while taking advantage of labels would also need to maintain two versions. 3- Thus the "classic mode" was born as a way to have only one (labeled) interface to a library, yet not force users of this library to use labels at applications. I really liked this idea of Jacques, because we can put labels in the library interface to self-document it, yet remain backward compatible with code using the library without labels. Of course, users that want the additional safety of labels can provide them at application sites, where they will be checked by the type-checker. To me, this is an excellent compromise: while I usually don't put labels at application sites, I enjoy the additional documentation provided by labels in module interfaces. 4- Since we did not want to trash the OLabl approach immediately, the "commuting label mode" was introduced to 1- implement stricter checking of labels, making them mandatory at application sites if the function was declared with labeled parameters, and 2- support giving labeled arguments in a different order than in the function declaration. Actually, a third mode was considered that would implement strict label checking but disallow commutation, thus ensuring that a given piece of code would be correct under both label semantics ("classic" and "commuting"), but we weren't sure this had enough value to be implemented. 5- We considered putting compiler pragmas to select the label mode inside the source, possibly changing it around a piece of code, instead of a per-file compiler flag. OCaml currently does not have this notion of pragmas, and it is not completely clear how they interfere with, say, submodules (can I put the pragma inside a "struct"? if so, what it its scope?). So I decided to wait until the need for such a pragma was really apparent. But it can be done if really necessary. A year or so later, I'm still convinced this design is the most reasonable approach. Yes, having two modes is not nice, but it is a lot less bad than the alternatives. If one mode must go, I think it's the "commuting label" mode because of the backward compatibility issue (point 1) and the fact that multiple versions of the libraries are infeasible (point 2). So, the real questions I have for readers of this list: - How many of you use the "commuting labels" mode? - For those who use it, do you take advantage of commutation or do you use it mostly to benefit from strict checking of labeled arguments? - What is worse in your opinion: having two modes or removing the "commuting label" mode? Apologies for this long rant. - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr