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 QAA16694; Wed, 11 Apr 2001 16:08:06 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA16707 for caml-list@pauillac.inria.fr; Wed, 11 Apr 2001 16:08:06 +0200 (MET DST) 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 MAA12018 for ; Wed, 11 Apr 2001 12:48:23 +0200 (MET DST) Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f3BAmMf28850 for ; Wed, 11 Apr 2001 12:48:23 +0200 (MET DST) Received: from quatramaran.ens.fr (quatramaran.ens.fr [129.199.129.64]) by nef.ens.fr (8.10.1/1.01.28121999) with ESMTP id f3BAmMq10541 for ; Wed, 11 Apr 2001 12:48:22 +0200 (CEST) Received: (from fare@localhost) by quatramaran.ens.fr (8.9.3/8.9.3) id MAA25723 for caml-list@inria.fr; Wed, 11 Apr 2001 12:48:15 +0200 Date: Wed, 11 Apr 2001 12:48:15 +0200 From: Francois-Rene Rideau To: caml-list@inria.fr Subject: Re: [Caml-list] Future of labels, and ideas for library labelling Message-ID: <20010411124815.A25715@quatramaran.ens.fr> Reply-To: Francois-Rene Rideau Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0pre3us Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [Sorry about late mail and missing headers; am having problems with my caml-list to nntp gateway.] >: Jacques Garrigue > To summarize recent posts by various people, there are two approaches > for a universal mode: You left without discussion the approach suggested by Arturo Borquez, which is quite distinct from that by Chris Hecker: "An unlabeled argument should be labeled with the first available label in the declared type of the function being called." (together with "every function argument declared without label is given an implicit unique label sui generis"?) Potential benefits: * drop-in compatibility with both classic and label mode, for those who use consistently use either style. * allows for continuous change between both styles, depending on what one prefers for the function being written. * works well with fold and higher-order functions and currification. Potential Problems: * the order of the labels in the type matters, whereas it didn't, which implies compiler changes. I suppose the compiler must currently somehow handle order anyway, since even with a possible early canonical ordering of labels, you must handle functions that declare a varying subset of labels in the global pool. * it may break either the equivalence between (f x) and (f ~1:x), or the way numerical labels do not commute with other labels. * type declarations that change the order of labels now have some specialness in that they modify the meaning of positional parameters. This might be something some people would strongly dislike. Or maybe not. * type inference is made more complex, because of the interaction between labelled and unlabelled arguments. I admit I certainly don't have clear enough an idea of the problems to judge how doable it is, but if this proposal is doable, it seems to me that the benefits might be worth it, since it unifies classic and label modes. In all cases, I'd like to hear about what you think of such proposal, particularly so if you dismiss it. Let the fact that it was used in some ancient macroassemblers not make you scorn it. (I already tried to draw your attention to this approach in the same previous message when I suggested that a classic mode stdlib could be obtained from a labelled mode one by writing a camlp4 metaprogram that strips labels and dumps a wrapper library). [ François-René DVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] [ TUNES project for a Free Reflective Computing System | http://tunes.org ] The ancients stole all our ideas from us. -- Mark Twain ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr