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 LAA17430; Tue, 3 Apr 2001 11:34:08 +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 LAA17766 for ; Tue, 3 Apr 2001 11:34:07 +0200 (MET DST) Received: from ext.lri.fr (ext.lri.fr [129.175.15.4]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f339Y6f03040; Tue, 3 Apr 2001 11:34:06 +0200 (MET DST) Received: from pc87.lri.fr (IDENT:root@pc87 [129.175.8.106]) by ext.lri.fr (8.11.1/jtpda-5.3.2) with ESMTP id f339Y5u10761 ; Tue, 3 Apr 2001 11:34:05 +0200 (MET DST) Received: from lri.fr (IDENT:jcourant@localhost.localdomain [127.0.0.1]) by pc87.lri.fr (8.9.3/jtpda-5.3.2) with ESMTP id LAA11429 ; Tue, 3 Apr 2001 11:34:05 +0200 Message-ID: <3AC9990C.1BE1C75B@lri.fr> Date: Tue, 03 Apr 2001 11:34:04 +0200 From: Judicael Courant X-Mailer: Mozilla 4.72 [fr] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Xavier Leroy CC: caml-list@inria.fr Subject: Re: [Caml-list] Future of labels, and ideas for library labelling References: <20010403093527G.garrigue@kurims.kyoto-u.ac.jp> <20010403125314Q.garrigue@kurims.kyoto-u.ac.jp> <20010403105212.A15700@pauillac.inria.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hi Xavier, I understand the strong need for upward compatibility for O'Caml (note however that the time I have spent porting programs from an O'Caml version to another I negligible compared to the time I have spent designing/writing/debugging them) but I disagree with you on some points. > 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 am not sure the case of classes and objects is the same as the case of labels. As for modules I do not think they are an extension, even if their power is underused. Map and Set for instance are useless if you do not know how to apply a functor. > 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. I already said I disagree on this. We have a one semester course here that does not use the standard library because currified functions are ignored. Does that mean you should remove currified functions from the standard library? > But we quickly realized this was unfeasible. It's just too hard to > maintain two versions of the same libraries. Why? I do not see the problem with the tool I have suggested? (a tool taking as input an interface file with labels and generating both the interface file without labels and a stub implementation). > 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 disagree with you: if I write an object-oriented library, I do not feel the need to provide a non-object-oriented version of it. Users will use objects or will not use the library. I think the same applies for labels. Judicaël. -- Judicael.Courant@lri.fr, http://www.lri.fr/~jcourant/ (+33) (0)1 69 15 64 85 "Montre moi des morceaux de ton monde, et je te montrerai le mien" Tim, matricule #929, condamné ŕ mort. http://rozenn.picard.free.fr/tim.html ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr