From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA10628 for caml-redistribution@pauillac.inria.fr; Sun, 2 Apr 2000 23:27:41 +0200 (MET DST) Resent-Message-Id: <200004022127.XAA10628@pauillac.inria.fr> 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 LAA10009 for ; Thu, 30 Mar 2000 11:43:47 +0200 (MET DST) Received: from localhost.localdomain (stan110.zip.com.au [61.8.17.110]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id LAA16375; Thu, 30 Mar 2000 11:43:19 +0200 (MET DST) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id TAA17204; Thu, 30 Mar 2000 19:39:30 +1000 Sender: root@localhost.localdomain Message-ID: <38E320D2.6F67964C@maxtal.com.au> Date: Thu, 30 Mar 2000 19:39:30 +1000 From: John Max Skaller X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christophe Raffalli CC: Jacques Garrigue , Xavier.leroy@inria.fr, caml-list@inria.fr Subject: Re: Semantic of label: The best (only ?) solution to merge both mode References: <38D35B51.8EB15DA0@univ-savoie.fr> <20000319112913P.garrigue@kurims.kyoto-u.ac.jp> <38E1C205.813AD040@univ-savoie.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-From: weis@pauillac.inria.fr Resent-Date: Sun, 2 Apr 2000 23:27:41 +0200 Resent-To: caml-redistribution@pauillac.inria.fr Christophe Raffalli wrote: > Then you can implement the following rule for applying a function to an > argument: > > f (a:l) means a is the argument corresponding to the first occurence of > the You mean f (l:a) > label l in the type of f (optional or not) (permuttation are > possible) > > f a means a is the argument corresponding to the first non > optionnal > argument of f Which 'default' arguments are passed when? > This is quite simple to explain and use and > modifying the actual code to get this is trivial (I can post it if you > want, but it does bootstrap because I did not modify the library which > does not respect any of the restrictions). This means that f (l:a) is a version of f with one parameter bound to a, like (f a), except currying can now be done on any argument? Hmm. So we could write: f la:a x lb:b y z lc:c ... which now means: (((((f la:a) x) lb:b) y) z) lc:c) When the last argument is 'used up', all remaining optional arguments are bound and the 'final' function applied? > I see only two problems: > > - One must make existing library compatible with one of the restriction: > I think the restriction is not too strong because we have not to always > write labels when applying functions. I agree. Mandatory writing of labels on definition is not as onerous as mandatory writing on use. > What do you think about this ? This gives the olabl people their old labels back, while merely requiring classic uses to decorate definitions with labels. In this case a temporary compiler mode switch to allow classic users to upgrade piecemeal would be ideal. To me, this proposal appeals. (Will it work? Do I understand it?) -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net