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 KAA09918; Wed, 11 Apr 2001 10:29:33 +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 KAA09913 for ; Wed, 11 Apr 2001 10:29:29 +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 f3B8TRf26454 for ; Wed, 11 Apr 2001 10:29:27 +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 RAA28027 for ; Wed, 11 Apr 2001 17:29:19 +0900 (JST) To: caml-list@inria.fr Subject: Re: [Caml-list] Future of labels, and ideas for library labelling In-Reply-To: References: <20010410123756H.garrigue@kurims.kyoto-u.ac.jp> 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: <20010411172919K.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 11 Apr 2001 17:29:19 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk The situation seems to have calmed down a bit. Or is it just that there is another more active thread? Anyway, I think that the conclusion is not very far. At least, we have collected all known problems about labels, and tried to answer them. Here is a summary of the plan I tried to draw from many people's contributions (and my own experience and convictions :-)): * remove labels from standard libraries * make label mode the default (and practically unique) mode; this preserves compatibility with ocaml 2.x * slightly extend it to allow non-labelled complete applications of functions: this is non-ambiguous, but keep a warning for purists, and also because of the slight mismatch between program text and untyped semantics * put some labels in alternative versions of a few libraries (List, Array, Unix). Access to these libraries would use already existing ways: "open Stdlabels", "module Unix = Lunix" * also add alternative labelled versions for the few functions with more than 4 arguments in the standard library (e.g. String.blit') I didn't get explicit support for the last addition: allow some non-labeled applications. Is it useful for some people, or should we avoid it for the gap in the semantics? If you're happy with all that, silent consent is enough. If you think this still misses the point, or something could be improved, explain yourself, but please do not make proposals: there is a very high probability that they are going to be flawed at either the typing or semantics level, and this is very hard to integrate them in the vision. Here are some very short answers to many suggestions. Sorry if I forgot some. To Claude Marche: > Could it be interesting that have such an option, > i.e. allowing at most one non labelled argument ? I think this is the right way to label most functions. But you cannot enforce that, because of currying. Also, in some cases the non-labelled argument is split in two related arguments (something like base and offset), so you don't need to be too strict on the form. The idea matters. To John Skaller: > Doesn't this simply suggest that the library author should not > put labels on functions with a small number of obvious arguments? (S)he is free to do that. But I wouldn't support this idea; this lacks coherence, and is not really needed. Most higher-order functions do take functions of only one argument, and in most cases this argument happens (and not by chance) to be the one left unlabelled in the function type. The experience is that in most cases eta-expansion is not even needed. In fact labels may even avoid it, since the unlabelled argument is not always the last one. To Brian Rogoff: > I know you'll hate this, but what about insisting on an explicit type for > functions which use commuting labels? Could something like that be made to > work? No hate involved here. This is exactly what the example with subtyping demonstrated in my previous mail: this cannot be made to work without badly breaking the semantics. Classic mode and commutation (even with explicit types) are fundamentally incompatible. Also, I didn't really see any strong support for labels in classic mode: labels without commutation are not so much fun. To Michael Sawka: > Unless I am missing something, I don't see how you can reconcile > normal function application with commuting labeled arguments within > the current type system. Thank you for joining the discussion, but this is really what label mode is about, and it just happens to work, and be relatively simple (when you don't mix with optional arguments). What you have is a conservative extension of lamba-calculus (using the default empty label), where you can also pass arguments on a different label, all this compiled to plain lambda code for a 0-cost execution model. Cheers everybody, Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr