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 MAA28168; Fri, 30 Mar 2001 12:31:15 +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 MAA28133 for ; Fri, 30 Mar 2001 12:31:14 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f2UAVBX28088 for ; Fri, 30 Mar 2001 12:31:12 +0200 (MET DST) Received: from localhost (sansho.kurims.kyoto-u.ac.jp [130.54.16.90]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id TAA24143; Fri, 30 Mar 2001 19:30:59 +0900 (JST) To: gurr@mrs.med.ge.com, caml-list@inria.fr Subject: RE: [Caml-list] Future of labels In-Reply-To: <200103300810.AAA05312@mrs.mrs.med.ge.com> References: <200103300810.AAA05312@mrs.mrs.med.ge.com> 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: <20010330193121X.garrigue@kurims.kyoto-u.ac.jp> Date: Fri, 30 Mar 2001 19:31:21 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: David Gurr > > On the other hand Manuel expresses an opinion I've heard a few times: > > moving to label mode might be nice, if the price to pay was not so > > high. > > That is my feeling. I appreciate the "new" features in moderation. > You type checker example is a good one as are the use of objects in > ocamlop. But I like being able to bootstrap Ocaml from the (caml-light > equiv.) core langauge. So I would like to remove labels from the > standard library and the bytecode compiler code (I haven't looked > carefully but I dont remember any there). Indeed, the bytecode compiler is very conservative (and has to be so). You will find some decorative labels in asmcomp (not mine). The reason we allow labels currently in the standard library (interfaces only) is that they are ignored in classic mode. If they are no longer ignored by the default mode, they will of course have to go. > > So, you are rather a frustrated potential label mode user than a happy > > classic mode user ? > > Mostly a caml-light mode user but I use the ocaml extensions when they clean > up otherwise messy code. I got pretty frustrated when I wanted to > compile (IMHO perfectly fine) 2.x code together with lablegtk. If > there was a 2.x to 3.x translator that added the labels for me, I would have > been merely anoyed with the added verbage. Removing labels from > the standard library doesnt help if someone label-ifies another > pre-3.00 library that I am using. Always the same confusion: you don't have to use label mode for lablgtk. Unison's GUI is rather large, and is completely written in classic mode. Concerning 3rd party libraries, this might of course be a problem, but I would expect a much smaller impact. The authors will take responsible decisions. > Although I'm in agreement with maf, I dont think that I would be > happiest with option 3. > > I don't like having both label and classical. Well, getting everybody to agree on a single mode is not going to be easy... More seriously, I insisted that this nolabel mode would be demoted, just kept for people with a fundamental allergy to labels (why not?), or some relabeling magic. The main problem with having two modes currently is that people wrongly assume that they have to be in one to do the work, while it can be done efficiently in both (independently of the libraries!). > I think that label is best in the long run. > > I think what I want are > > -- label mode only > -- restrained labels in the standard library I think none by default is more reasonable. But it might be nice to keep the labels in otherlibs like Unix. They would of course stay in LablTk :-) > -- a 2.x to 3.x translator Not needed, as long as we remove labels from the standard library. Really, such a translator is possible, but I don't like very much the idea of a program fiddling with my code... Remark that this would not be a 2.x to 3.x translator, but a classic to label translator. Anyway the translator only fixes your code, not your habits. My intimate belief is that changing habits takes longer than changing code, and by translating by hand you will learn faster :-) (maybe not currently valid, because of the standard library) > -- a (partial) 3.x to 2.x translator that complains & gives up when > there is not an obvious 2.x translation but good enough to de-label > the standard library. Possible again, but much more work: we must type the program, apply some non-trivial transformations to it, and output it again. An early version of olabl based on caml-light worked that way, but honestly this was a pain. Also, compiling optional arguments that way would produce really obfuscated code. > So what about ~f:? I dont like ~f: and you do. Suppose I had an > editor that puts in the ~f: for me AND hides it so I won't see it > in the cases when it is in the first arguement? Or even better, > the editor takes your code with the :) backwards arguement order, > puts the arguements in the :) proper order and hides the ~f: > :) cruft. Now I even happy with the most excessively label'd > libraries. I think. Well, this would still mean two modes. I don't think that classic and label are bad in this meaning: they were design to interact properly. But people are always going to meddle with each other, and you want to be able to exchange code snippets by mail for instance. Cheers, Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr