Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] labels and optional arguments in 3.06
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] labels and optional arguments in 3.06
From: Chris Hecker <checker@d6.com>

> >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