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 FAA21838; Mon, 2 Apr 2001 05:52:03 +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 FAA21803 for ; Mon, 2 Apr 2001 05:52:01 +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 f323koj10435 for ; Mon, 2 Apr 2001 05:46:56 +0200 (MET DST) Received: from localhost (mikan.kurims.kyoto-u.ac.jp [130.54.16.202]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id MAA15286; Mon, 2 Apr 2001 12:39:58 +0900 (JST) To: yminsky@cs.cornell.edu Cc: caml-list@inria.fr Subject: [Caml-list] Future of labels, and ideas for library labelling In-Reply-To: References: 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: <20010402123958K.garrigue@kurims.kyoto-u.ac.jp> Date: Mon, 02 Apr 2001 12:39:58 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk More answers, and more prespectives. That's all very nice. Globally it seems that almost everybody would prefer a single mode. This is also my point of view: staying with two "equal" modes is confusing. Originally this was an attempt to keep most of the progress made in olabl (with label mode) for people with an olabl background, while the classic mode was intended to be the main mode for people used to ocaml. I hoped that maybe just a few people might switch to label mode, and more importantly classic mode users would start using labels in classic mode. This is the lack of progress in this last direction that makes me thing this will not work as well as I hoped: there is little point in having labels in the standard library if most 3rd party libraries do not labelize their APIs. Then it is better to have one single community adapt slowly. This said, at last we got an answer from a "happy classic mode user". At least my attempt was not completely absurd :-) From: "Yaron M. Minsky" > I make heavy use of labels in classic mode both for the > extra type safety it provides and for documentation. I > find it to be extremely useful, and would be sad to see > classic mode go. I've never felt a great need for commuting > of non-optional arguments. LablTk, at least, seemed quite > usable in classic mode. > > The idea of stripping labels out of the standard library > seems like a mistake. The main thing I like about labels > is the extra safety they provide. For example, the ~key > and ~data labels for the function in Map's iter is very > useful, particularly when the key and data happen to be the > same type. Thank you very much. I was starting to feel a bit depressed about the outcome of the classic mode. Still, if there is only one mode to keep, I think it is better to keep the label mode, both because it is more powerful (commutation matters for some users) and because it is better understood theoretically (cf. the silly soundness problem in classic mode). 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. 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'. Since their number is very small, this would not mean too much code increase. If we have these functions, then labellers would probably be happy with a Stdlabels module containing just labelized version of List and Array. (Keeping this compatibility module small is good to avoid confusion). However, while the duplication approach (at a function or module unit) seems to be the only possible for the standard library, it would be awkward for other libraries. So the next question might be, are people ready to have some mandatory labels in the Unix library? And how much? Removing labels from the Unix library makes code less redable, and more error prone, particularly since many arguments have the same type. (See how easier it was to understand the last code snippet posted on this list, where Unix.create_process was used with labels.) The graphics library being more beginner oriented, I'm not sure keeping labels there would be a good idea. Last, there would still be a "nolabel" mode left, but this would be mostly for technical reasons, and would not be explicitly supported anymore after a transition period. Jacques Garrigue P.S. A few other points from the orginal poster. > I agree that having ocaml have one standard mode would be > best, if possible. If there continue to be two modes, I am > strongly in favor of a pragma for specifying the mode on a > file-by-file basis. Second request. If we stay with two "equal" modes, that may get through. > (On another note, it would be lovely if one of these days > ocaml could move to something like the alternative syntax > shipped with camlp4. There are a number of bits of the > caml syntax that are quite counterintuitive, most of which > are fixed with the alternative syntax.) That would be much harder for compatibility reasons. Yet I understand camlp4 might get into the standard distribution. Maybe not so nice for people attached to a unique mode, but if you don't care that may become a real alternative. ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr