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 JAA25535; Mon, 2 Apr 2001 09:58:22 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 JAA25550 for ; Mon, 2 Apr 2001 09:58:21 +0200 (MET DST) Received: from ext.lri.fr (ext.lri.fr [129.175.15.4]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f327wKD06025 for ; Mon, 2 Apr 2001 09:58:20 +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 f327wGu26047 ; Mon, 2 Apr 2001 09:58:16 +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 JAA07199 ; Mon, 2 Apr 2001 09:58:15 +0200 Message-ID: <3AC83117.7C3AD3C9@lri.fr> Date: Mon, 02 Apr 2001 09:58:15 +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: Jacques Garrigue , caml-list@inria.fr Subject: Re: [Caml-list] Future of labels, and ideas for library labelling References: <20010402123958K.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Jacques Garrigue a écrit : [...] > But if we manage well the transition, I believe we can keep most of > the advantages of classic mode, while getting labels out of the way of > beginners. > I think beginners are not the problem. Explaining that you have labels and that arguments may commute seems quite easy to me (of course I will have to revise my teaching material, but I think that is another point). At least it is an order of magnitude easier than explaining partial application and currying (that is, if you do not consider optionnal arguments). To address Benjamin Pierce's concerns, I think teaching Java is another problem as in Java you have no toplevel, so you must use the standard library for doing I/O from the beginning. When beginning to teach Caml, you can use the toplevel and therefore ignore the standard library for a while (although I would not advocate for it, we have a "functionnal approach" undergraduate course here that completely ignores currying hence the standard libray for a whole semester!) Rather, I am concerned with upward compatibility. [NB: In the following, I often use "should". Please consider there is an "In my humble opinion" before each of these uses] You should not sacrifice the Right Way (tm) for compatibility. I mean, the default way to write a program should be the Right Way (i.e. with labels): you should encourage people writing a new program/module to use labels (while allowing people to compile their old code with few changes). > First, concerning the standard library, an idea would be to first > remove all labels from the default versions, but then add labelized > versions of some specific functions with a different name (adding a > "'" for instance). > I mostly think of: 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'. So I think this is the Wrong Approach (tm). Instead, you should provide an CompatLib (or WithoutLabels) compatibility module for old code and a possibly a flag for compiling code with an implicit "open CompatLib". As for other libraries, the Right Way is to have the default libraries with labels also. Then either you suggest them to move to the Right Way, or you provide them the needed CompatLibs. BTW, I guess writing a tool for "unlabeling" a library would be quite easy, would not it? (parse the mli of the labeled library, remove labels for producing the corresponding unlabeled mli, and generate the wrapper ml file --- the only difficult part is with concrete types). Such a tool would let you focus only on the maintenance of one library. Moreover, after some time, you could decide to remove support for CompatLibs while still let people explicitly generate their own unlabeled libraries with this tool. Sincerly yours, 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