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 JAA30724; Thu, 14 Nov 2002 09:23:52 +0100 (MET) 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 JAA31152 for ; Thu, 14 Nov 2002 09:23:52 +0100 (MET) Received: from favie.faith.gr.jp (favie.faith.gr.jp [61.127.175.250]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id gAE8Nm122073 for ; Thu, 14 Nov 2002 09:23:50 +0100 (MET) Received: from localhost (dhcp7.faith.gr.jp [192.168.1.17]) by favie.faith.gr.jp (8.9.3/8.9.3) with ESMTP id RAA20624; Thu, 14 Nov 2002 17:23:41 +0900 To: checker@d6.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] labels and optional arguments in 3.06 In-Reply-To: <4.3.2.7.2.20021113204718.031fa750@localhost> References: <4.3.2.7.2.20021113184428.030a3a38@localhost> <20021114123418O.garrigue@kurims.kyoto-u.ac.jp> <4.3.2.7.2.20021113204718.031fa750@localhost> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20021114172307R.garrigue@kurims.kyoto-u.ac.jp> Date: Thu, 14 Nov 2002 17:23:07 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Chris Hecker > >Indeed, that would leave no ambiguity. So it might be ok to allow > >mixing labelled optional arguments in an otherwise unlabelled > >application, if there is no ambiguity on labels. But is it really > >worth a strange definition, when the workaround is just to add > >parentheses? > > I appreciate your point here about compiler complexity, but I'd say the > answer is yes. The parentheses just add to the syntactic mess, they don't > help with it and make things clearer (which is the original point of > labels). It's preferable to just not use the labels than to bizarrely > parenthesize functions, I think. Imagine reading some code and looking at > a function call with parentheses like that, knowing that currying makes it > so there's no need for them if there were no labels. You'd have to stop > and think about what was going on. So, I'd say that's a readability > lose. It'd be better to just punt the labels and optional arguments > altogether, because at least then the code is "normal". This is indeed the simplest answer: if you don't intend to put labels in your code, you can do without them on non-optional arguments. But you don't have to punt optional arguments altogether. This problem only appears when you have labelled arguments AND optional arguments AND you don't want to label the labelled arguments in your function application. And if your concern is really readability, I maintain: more verbose (in reasonable limits) is more readable, and writing those labels in applications cannot be an inconvenient when reading your code. Languages like smalltalk have only compulsory labels. > How hard would it be to implement this rule? The trouble is that the rule is not unique. A possible one (and easy to implement) would be an iterative definition: * if the first parameter of the function is labelled, and this label is provided in the application, then match their types, and start again with the rest of the type * if the first parameter of the function is unlabelled, and there is an unlabelled argument in the application, then match their types, and start again * if the first parameter of the function is optional, and there is no argument by that label, and there are some unlabelled arguments in the application, then that parameter is erased; discard it and start again * otherwise, if all remaining arguments in the application are unlabelled, and there are as many arguments as non-optional parameters, switch to unlabelled application (optional parameters are erased, non-optional ones taken in order) * otherwise, switch to labelled application (some parameters may be ommited) Not only this is a long definition, but it is not symmetric. It would allow ommiting labels in val f : ?a:int -> b:int -> int but not in val g : a:int -> ?b:int -> unit -> int A fully symmetric definition is much harder to obtain, and to implement. Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners