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 CAA25230; Fri, 15 Nov 2002 02:09:31 +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 CAA25240 for ; Fri, 15 Nov 2002 02:09:30 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id gAF19S116039 for ; Fri, 15 Nov 2002 02:09:29 +0100 (MET) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id KAA07319; Fri, 15 Nov 2002 10:09:25 +0900 (JST) 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.20021114102309.041f3dd8@localhost> References: <4.3.2.7.2.20021113204718.031fa750@localhost> <20021114172307R.garrigue@kurims.kyoto-u.ac.jp> <4.3.2.7.2.20021114102309.041f3dd8@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: <20021115100924V.garrigue@kurims.kyoto-u.ac.jp> Date: Fri, 15 Nov 2002 10:09:24 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Chris Hecker > >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. > > I would restate this (to conveniently make it sound less radical/more > radical in my favor :). If you are using labels primarily for > documentation, but you rarely if ever apply them on calls, and then you > want to use optional arguments, you are suddenly forced to always use > labels on those calls. This could force you to label zillions of calls in > your huge codebase when you add an optional argument to a label-documented > function, but wait, that goes completely against the intent of optional > arguments (that you don't know they're there unless you care)! Therefor, > one is incented to not use labels at all. Sorry, you're wrong. The problem only appears when you actually want to pass an optional argument. If you are adding this optional argument afterwards, this will not disturb existing function calls that do not use this optional argument. Labels may only be needed on new code. No, really, you're making a big fuss for a tiny case. On a different subject, there is a nice property in writing labels in applications: this means that you can make these arguments optional afterwards, without any need to change old code. While the type checker allows you to ommit the labels, you then loose that property. > >A fully symmetric definition is much harder to obtain, and to > >implement. > > It's not worth it if it doesn't "just work" in all cases (except > cases with duplicate labels). That's exactly the problem: my "simple" (already complicated) definition doesn't handle all cases. 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