From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA05196 for caml-redistribution@pauillac.inria.fr; Thu, 6 Apr 2000 15:24:27 +0200 (MET DST) Resent-Message-Id: <200004061324.PAA05196@pauillac.inria.fr> 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 IAA03342 for ; Tue, 4 Apr 2000 08:54:15 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id IAA08869 for ; Tue, 4 Apr 2000 08:54:13 +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 PAA24787; Tue, 4 Apr 2000 15:53:25 +0900 (JST) To: bpr@best.com Cc: skaller@maxtal.com.au, caml-list@inria.fr Subject: Re: to have labels or not In-Reply-To: Your message of "Wed, 29 Mar 2000 12:32:18 -0800 (PST)" References: X-Mailer: Mew version 1.93 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000404155325J.garrigue@kurims.kyoto-u.ac.jp> Date: Tue, 04 Apr 2000 15:53:25 +0900 From: Jacques Garrigue X-Dispatcher: imput version 980905(IM100) Resent-From: weis@pauillac.inria.fr Resent-Date: Thu, 6 Apr 2000 15:24:27 +0200 Resent-To: caml-redistribution@pauillac.inria.fr From: Brian Rogoff > I agree with John Skaller on this. Two libraries seems like a better > compromise than two modes. There is also some precedent here in that > the standard libraries were never "OO-ized" after an object system was > added to Caml. Finding a mode which would allow OO-izing the standard library while keeping backward compatibility would be a nice challenge :-) We could discuss very long on the two library vs. two mode approaches, without reaching a conclusion. Both have their own merits. However an important point in this choice is just practical implementation problems: * using the current OCaml techniques, like MD5 identification of module interfaces, linking of codes based on different libraries is not possible. Moreover, making it possible without code duplication is not trivial. * maintaining concurently two different standard libraries would be a pain. It was already with olabl. And what about Str, Dbm or Unix, which can naturally profit from similar labellings. * on the other hand, the two mode scheme only requires a few lines in the compiler. Basically switching on or off some checks, and a slightly different treatment of function application. So I believe that having 2 modes was a rather natural first choice. Now, if we realize after some time that this was not a good choice, it will still be possible to change it for another approach. Of course with a transition as painless as possible, and with the core language preserved. > There just doesn't seem to be a good solution to this problem, i.e., one > which will leave everyone happy. This is the human engineering part of > programming language design, and since it appears a lot of Caml programmers > find labels too heavy for their programming style I think we should go > with the rule "When in doubt, leave it out". Out of the standard library > that is. I'm not happy with this, as I prefer the labeled style, but it > appears that the community is already somewhat split. Keep cool, we are not talking about divorce :-) If we let conservatism decide on all subjects, there is no possible progress. Are we going to have people to vote about what scientific theories they like, or (more accurate) which novel writers should be published and which not? Let's leave people more time to decide what they want for themselves. Then at that point there may be a better solution, which an early decision would not have discovered. Best regards, Jacques P.S. If I remember correctly, you asked a while ago about what would happen of olabl polymorphic methods. In fact, there is no progress since last Christmas, and I still view it the same way. When 3.00 is released, I may start writing a quick patch based on olabl code. If after a while I can come out with something stable enough and that would not slow down the compiler, I think there would be no specific problem in including it in the main compiler. But I have no idea of when. For the time being, either you have to stick to olabl 2.04, or find a workaround without polymorphic methods. My experience is that for most non-theoretical uses there are workarounds. --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp JG