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 LAA18231; Tue, 3 Apr 2001 11:52:13 +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 LAA18276 for ; Tue, 3 Apr 2001 11:52:12 +0200 (MET DST) Received: from psyche.kaba.or.jp (psyche.kaba.or.jp [202.249.19.1]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f339q6f03889; Tue, 3 Apr 2001 11:52:06 +0200 (MET DST) Received: from vortex.kaba.or.jp (vortex.kaba.or.jp [202.249.19.21]) by psyche.kaba.or.jp (8.9.3/3.7Wpl2-psyche) with ESMTP id SAA50143; Tue, 3 Apr 2001 18:52:01 +0900 (JST) Received: from localhost (pmdhcp06.kaba.or.jp [202.249.19.118]) by vortex.kaba.or.jp (8.9.3/3.7W) with ESMTP id SAA28525; Tue, 3 Apr 2001 18:52:00 +0900 (JST) To: Xavier.Leroy@inria.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] Future of labels, and ideas for library labelling In-Reply-To: <20010403105212.A15700@pauillac.inria.fr> References: <20010403125314Q.garrigue@kurims.kyoto-u.ac.jp> <20010403105212.A15700@pauillac.inria.fr> 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: <20010403185448J.garrigue@kurims.kyoto-u.ac.jp> Date: Tue, 03 Apr 2001 18:54:48 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Salut Xavier, I'm a bit surprised by your post. Yes this discussion is lively. But it is calm, and we just try to find the Right Way. I'm not sure it was the case last year, so I wouldn't discard this discussion as useless. > 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"... This doesn't dispense us of trying to find a good solution. Last year's change was 100% compatible, but I think that during our discussions before the release we also talked of non 100% compatible approaches. The real question is to make the cost of transition neglectible, isn't it? And not to have to change again. > 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. I made some proposals to make the differences small enough that this would be easy to maintain. One important trouble yet is where is the limit between standard libraries and other libraries. > 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. I sincerly hoped this would work. Unfortunately, I see not very much enthusiasm for the classic mode. > 4- Since we did not want to trash the OLabl approach immediately, the > "commuting label mode" was introduced Huh, strange view of history. > 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). I understand perfectly well point 1 (to a certain extent), but I'm not so sure point 2 is really a problem if we are not too ambitious. > So, the real questions I have for readers of this list: > > - How many of you use the "commuting labels" mode? I do. But I don't like votes. > - 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? Both, of course. > - What is worse in your opinion: having two modes or removing the > "commuting label" mode? I do not see where this alternative comes from. Classic mode was designed as an interaction mode with label mode. I wouldn't consider it very interesting on its own. (That's maybe its main drawback) Apologies for the short tempered reaction. Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr