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 FAA20901; Fri, 30 Mar 2001 05:01:21 +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 FAA21016 for ; Fri, 30 Mar 2001 05:01:17 +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.11.1/8.10.0) with ESMTP id f2U31FH05377 for ; Fri, 30 Mar 2001 05:01:15 +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 MAA18903 for ; Fri, 30 Mar 2001 12:01:12 +0900 (JST) To: caml-list@inria.fr Subject: RE: [Caml-list] Future of labels 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: <20010330120112L.garrigue@kurims.kyoto-u.ac.jp> Date: Fri, 30 Mar 2001 12:01:12 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Nice, it seems that we can have a relaxed discussion this time :-) OK, I'll first try to correct some (potential) misunderstandings. * I'm not sure this is a misunderstanding, but at least it may seem that some (Chris, Arturo) are implying that optionals argument do not commute in classic mode. They do commute in both classic and label mode, and there is no plan to change this behavior. That means that if you are only interested in labels on optional arguments, classic mode is already enough. * The possibility to "omit labels" in classic mode, and to "omit optional arguments" in both modes may be confusing. These are completely unrelated features: the worst wording would be to say "labels on non-optional arguments are optional in classic mode" * The rules in the P.S. of my previous mail describe a potential new version for _classic_ mode. This does not replace label mode. * From both theory and implementation point of view, classic mode is not simpler than label mode. They both share optional arguments, which is the most complex part. Otherwise it seems that we've got a nice array of answers, covering everything from the die-hard non-labelist (Chris) to the die-hard labelist (myself). Sorry for Judicael, but I see no way to satisfy everybody with a single mode. (You don't expect me to just drop the label mode, and be happy with classic, no ?) Yet, I see no strong support for the label features of classic mode: * decorative labels in interfaces (I thought it could be very useful, particularly if one uses ocamlbrowser.) * the ability to write labels in the code, just to increase safety 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. To keep the discussion open, here is a 3rd alternative, which involves making label mode the default mode, removing labels from the standard library (to keep compatibility with ocaml 2, that's paramount), and keeping a simplified classic mode for those who don't want to hear of labels at all. * Label mode as default, with no labels in the standard library This makes moving to label mode very easy, the only needed modifications are when using new libraries that have labels. For current label mode users, some (partial) compatibility libraries would be provided, so that they (I?) don't have to drop all their dear(?) labels. (I'm mostly concerned with Pervasives, List, Array, String, and Unix) * The simplified classic mode would simply prohibit writing labels on non-optional arguments in function application. You're free to write them anywhere else (abstraction or interfaces), but they are simply ignored, and never cause a type error. Basically that means that the only rule for non-optional parameters is (fun ~l:x -> e) v --> e[v/x] That makes all the theory simpler, and we recover soundess :-) Only problem: it is no longer possible to write everything in the intersection of classic and label mode. I generally try to do this when I write examples, but this would become impossible with some libraries. As a result this mode would have to be demoted: documentation is written for default mode, and no-label mode users are on their own to remove spurious labels. Even demoted, label users might still need it for some administrative tasks, like adding a labeled interface to a non-labeled library. Would Chris (who doesn't write the labels anyway) be happy with something like that ? Would others enjoy moving to label mode at no cost (with libraries compatible with 2.x) ? That is, would they be ready to write more labels when they use labeled libraries (like labltk) ? Are there some real users of classic mode around (who use what I called its "label features"), and would they fit in any of these two categories ? How much do label users care for having labels in the standard library? Here are a few more answers to Manuel, whose post was closest to this proposal: From: "Manuel Fahndrich" > I use label in classic mode, mostly to disambiguate arguments of the > same type and a little bit for documentation. Nice, a real classic mode user! > To see if I could do with modern mode, I tried to compile my current > code base with -modern. This seems to not be too bad, except for 2 > things, one being a show stopper: > > 1) The standard library requires ~f: labels on many function arguments. > That seems silly. I basically had to add ~f: to many places where it did > not add disambiguation (f is not a very explicit name). I can see that > for partial applications that might be useful, but still I found this a > bit annoying. Not really for partial application (you rarely want to apply to a list before the function), but rather for layout. Mostly a question of taste, but if you like it really changes the way you use functionals. Anyway, if we remove labels from the standard library, this would solve the problem. > 2) If some library function requires a function argument with labeled > arguments, such as Map.fold f:(key:key -> data:'a -> 'b -> 'b) > and I happen to have a function around that would do the right fold > operation, except that it is unlabeled or has different labels, then I'm > stuck. I have to write an eta conversion. Why isn't an explicit cast to > change the labels of a function sound? I tried that and it didn't work. The notion of soundness being with respect with an untyped reduction semantics (cf http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/), changing labels through a cast cannot be sound... Is it that big a problem in practice ? I really doubt it: I discussed it with some heavy Haskell users, and repeatedly got the answer that they don't use fold because this produces unreadable code. Labels and eta-expansion are just necessary steps to make it readable. Anyway, if we remove.... > Other than the above, it seems that a casual user like me could move > from classic to modern, especially if there are some further benefits > like partial applications in different orders. One thing that needs > improvement though are the error messages. Because the compiler tries to > reorder arguments etc., forgetting a label spits out really whacky > messages like, this function expects too many arguments. So, you are rather a frustrated potential label mode user than a happy classic mode user ? Cheers, Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr