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 RAA19164 for caml-redistribution@pauillac.inria.fr; Wed, 22 Mar 2000 17:11:31 +0100 (MET) Resent-Message-Id: <200003221611.RAA19164@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 AAA30358 for ; Wed, 22 Mar 2000 00:23:41 +0100 (MET) Received: from localhost.localdomain (krusty43.zip.com.au [61.8.16.43]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id AAA12078 for ; Wed, 22 Mar 2000 00:23:31 +0100 (MET) Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id KAA09094 for ; Wed, 22 Mar 2000 10:29:17 +1100 Sender: root@localhost.localdomain Message-ID: <38D805CD.78032EB3@maxtal.com.au> Date: Wed, 22 Mar 2000 10:29:17 +1100 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: caml-list@inria.fr Subject: Re: Syntax for label, NEW SOLUTION References: <38D35B51.8EB15DA0@univ-savoie.fr> <20000319112913P.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-From: weis@pauillac.inria.fr Resent-Date: Wed, 22 Mar 2000 17:11:31 +0100 Resent-To: caml-redistribution@pauillac.inria.fr Jacques Garrigue wrote: > There is a misunderstanding here. There are currently two > communities, and one goal of the merger is to have a big caml > community again. I think that having two modes is a good way to reach > this goal. I do not: in the short term, two modes is a good compromise. In the longer term, one language is better. I am glad for the two modes at present. I hope they will go away in the future. > > o The fact that you've had to resort to "modes" at all indicates something > > is wrong. > Well, before that there were two compilers. I think this is a progress. I agree. Particularly, I was attracted by some of the olabl software but was not willing to use two compilers. Now I have the nice olabl software, and still have my ocaml software too. > > If we could come up with a semantics where labels are always optional, > > I think I would accept things like acc in the standard library. But > > when you have to make a choice between optional labels and no useful > > functionality, it's a harder sell. > > Some people really want to eat the cake and still have it. Sure, why not? > I already explained a while ago why it was not possible to have labels > both optionals and commuting in a curried language. Sure it is. The question is whether the error messages are readable. Python supports 1) positional arguments 2) labelled arguments 3) default values for missing trailing positional parameters 4) optional labelled AND positional arguments It does not support currying, but it does diagnose missing arguments, and such could be re-implemented as partial applications. FYI the rules are: for a definition: def f(x,y,z=1,q=2,*args, **kwds): ... and calls f(1,2) f(1,2,3,4,5,6,7) f(1,z=6,y=4, extra=22) 1) bind parameters to the given positional arguments positionally. If there are too many, the extra ones go into the tuple 'args' if given, else error. 2) try to bind the remaining positional arguments from labelled ones. If there is a duplication of labelled and positional arguments, error. If there are still missing required arguments, then use the default if there is one, else error (change to 'curry' for our purposes) 3) if **kwds is given, put all the labelled arguments into dictionary kwds (even those used to fill in required arguments) 4) if there are excess labelled arguments and no kwds, then error. Thousands of Python programmers use this scheme every day. Currying missing arguments would disable error checking, so in Python you have to use a separate function definition. [This could actually be fixed by sugar: use f(x, curry) to signify intentional currying] I'm not suggesting to use thd Python scheme, only that it _is_ possible to support optional commuting labelled arguments and optional arguments, and default arguments, and variable length argument lists and arbitrary option sets coherently. > Do not confuse the fact of having two reasonably consitent modes with > having only one in which any strange thing is allowed. Also do not confuse 'we cannot think of a synthesis of the modes which makes sense' with 'there exists no such synthesis' :-) > That sounds reasonable. I would also personally prefer "f:" to "fn:". > My choice of labels has been driven by voices from olabl users who > insisted that labels should be as readable as possible, but having > short names is ok if they are readable. Still I would not support > reducing _all_ labels to 1 character, while it might be ok for most > of them in the standard library. Having a document for it is only > bearable as long as it is standard Why not allow several (synonymous) labels? let f c: chr: character: the_really_verbose_character: c' = c' -- 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