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 TAA22493; Tue, 17 Apr 2001 19:34:14 +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 TAA22536 for caml-list@pauillac.inria.fr; Tue, 17 Apr 2001 19:34:13 +0200 (MET DST) 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 TAA21587 for ; Wed, 11 Apr 2001 19:48:47 +0200 (MET DST) Received: from sarg.Ryerson.CA (sarg.ryerson.ca [141.117.18.117]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f3BHmjD08934 for ; Wed, 11 Apr 2001 19:48:45 +0200 (MET DST) Received: from sarg.Ryerson.CA (IDENT:dmason@localhost [127.0.0.1]) by sarg.Ryerson.CA (8.9.3/8.9.3) with ESMTP id NAA31483; Wed, 11 Apr 2001 13:48:24 -0400 Message-Id: <200104111748.NAA31483@sarg.Ryerson.CA> To: Jacques Garrigue cc: fare@quatramaran.ens.fr, caml-list@inria.fr Subject: Re: [Caml-list] Future of labels, and ideas for library labelling In-reply-to: Your message of "Thu, 12 Apr 2001 00:34:42 +0900." <20010412003442E.garrigue@kurims.kyoto-u.ac.jp> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Apr 2001 13:48:24 -0400 From: Dave Mason Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >>>>> On Thu, 12 Apr 2001 00:34:42 +0900, Jacques Garrigue said: > From: fare@quatramaran.ens.fr (Fran=E7ois-Ren=E9 Rideau) >> 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." > I might have worded my classification in this (less understandable > way all proposals have to choose between two types of unification, > strictly matching labels or ignoring them. > You must ignore them to be compatible with classic mode. You must > match them strictly to be compatible with label mode (provide > commutation with any decent semantics). I understand if you only want to implement one of those 2 choices, after all, it's your time. However, if it is a question of what should go into my (and many other people's) favourite language, I think taking those as the only 2 options is rather restrictive, and there are many other possible ways to do this. > So this is just impossible to be compatible with both > simultaneously. To some degree you may allow idioms of classic mode > in label mode (like dropping some labels), but not the other way > round, and not 100% compatible. I think you should reconsider the suggestion from Borquez (as encouraged by Rideau), because I think that it would support something very close to the best of both world (while remaining completely backward-compatible with `classic' mode). > This is the basic reason I didn't try to answer in detail all > proposals. I must admit I was rather concerned by the response to Remy where you said you needed all the parameters available at once. That is not functional programming as I know and love it! > The rule you describe here might also be seen as an alternative to > label mode (yet incompatible with classic mode). However it is not > compatible with label mode, semantics are a bit more complex, and > this idea of choosing label by label whether to write or not sounds > a bit too laxist to me (not a good reason, but the other two are). It may not be perfectly compatible with `label' mode, but it looks pretty darned close (although it wouldn't force as many error messages as perhaps you want). And it would be completely compatible with `classic'. Are those the ``other two'' you refer to? The important part to me, is that it would allow me to define labels on *all* my parameters (rather than having to choose which one is likely to be most useful to leave off), but only use them at application if I wanted to, and therefore to be able to use labeled functions with higher-order functions that use multiple parametered arguments (like fold), without the ugliness of (visible) eta-expansion. (If it does eta-expansion behind the scenes if it was not the last 2 parameters that I left unnamed, so be it. Just don't force me to uglify my code!) There is a syntax that would allow me to control the use of such arguments rather nicely, I think. Assume I have: f: ~a:int -> ~b:int -> ~c:int -> int I could use fold like: fold (f ~b:4 : ~c ~a) [1;2;3] 17 which would, behind the scenes be turned into, essentially: fold (function x -> function y -> f y 4 x) [1;2;3] 17 or: fold (f ~b:4) [1;2;3] 17 which becomes: fold (function x -> function y -> f x 4 y) [1;2;3] 17 or: fold (f 4) [1;2;3] 17 which would be the same as: fold (f ~a:4) [1;2;3] 17 which can be logically thought of as: fold (function x -> function y -> f 4 x y) [1;2;3] 17 but, of course, requires no such expansion. This may not be as interesting theoretically as the existing label mode, but it doesn't look that hard to do, and the unification rules look fairly easy to state. =2E./Dave= ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr