Re: [Caml-list] labels and optional arguments in 3.06

[Chris Hecker <checker@d6.com>]

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

Oops, you're right, sorry about that!  I actually typed the first complaint 
(forced to use labels when using optional argument), and then thought of 
the second point (spreading) afterwards, but I obviously didn't think it 
through (even my own experiments disproved that point :).  The correct 
second point would just be that now calls with the optional argument look 
different from calls without, so it's not local, in some sense.  But yes, 
that's a much less critical complaint.

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

Sure, but the thread is not about whether writing labels is good or bad in 
general (not a subject we want to ressurrect), it's just about the effect 
of optional labels on labeled functions.

>That's exactly the problem: my "simple" (already complicated)
>definition doesn't handle all cases.

I guess I figured there'd be a "simple" generalization that was easier.  Is 
the commuting property affecting the difficulty?  I also don't care about 
that feature.  :)

But anyway, if it's not relatively easy, I'll just let it die.

Chris


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