[Caml-list] labels and optional arguments in 3.06

[Caml-list] labels and optional arguments in 3.06

[Chris Hecker]

The new optional label semantics seem to work pretty well for my
normal usage, however I've run across one thing I'd like to do that
doesn't seem to work (and a warning I don't understand):

> # let f ?(a = 1.0) ~b ~c = a *. b *. c;;
> Characters 12-15:
> Warning: This optional argument cannot be erased
>   let f ?(a = 1.0) ~b ~c = a *. b *. c;;
>               ^^^
> val f : ?a:float -> b:float -> c:float -> float = <fun>

First question:  what is this warning?

Second question:  I'd like to be able to call f with or without
specifying the optional argument, without labels:

> # f;;
> - : ?a:float -> b:float -> c:float -> float = <fun>
> # f 2.0 4.0;;
> - : float = 8.

works fine,

> # f ~a:2.0 2.0 4.0;;
> Characters 9-12:
>   f ~a:2.0 2.0 4.0;;
>            ^^^
> Expecting function has type b:float -> c:float -> float
> This argument cannot be applied without label

doesn't work.  I'd like to be able to use ~b and ~c for interface
documentation, but not be forced to use them, and have ?a be an
optional parameter.  This

> # f ~a:2.0 ~b:2.0 ~c:4.0;;
> - : float = 16.

works, of course, but it's really verbose.

Is there any way to make this work?

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

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

[Jacques Garrigue]

From: Chris Hecker <checker@d6.com>

> The new optional label semantics seem to work pretty well for my
> normal usage, however I've run across one thing I'd like to do that
> doesn't seem to work (and a warning I don't understand):
> 
> > # let f ?(a = 1.0) ~b ~c = a *. b *. c;;
> > Characters 12-15:
> > Warning: This optional argument cannot be erased
> >   let f ?(a = 1.0) ~b ~c = a *. b *. c;;
> >               ^^^
> > val f : ?a:float -> b:float -> c:float -> float = <fun>
> 
> First question:  what is this warning?

It says that since there is no unlabeled argument after this optional
one, there is no way to "erase" it using normal rules. This is not
100% true with the new semantics, as passing all other arguments
without labels will do the job, but still this is not a proper
labelling.

> Second question:  I'd like to be able to call f with or without
> specifying the optional argument, without labels:
> 
> > # f;;
> > - : ?a:float -> b:float -> c:float -> float = <fun>
> > # f 2.0 4.0;;
> > - : float = 8.
> 
> works fine,

Yes, so the above (old) warning is not correct.
Maybe I can drop it altogether: there shall just be a non-optional
argument after an optional one, labelled or not.

> > # f ~a:2.0 2.0 4.0;;
> > Characters 9-12:
> >   f ~a:2.0 2.0 4.0;;
> >            ^^^
> > Expecting function has type b:float -> c:float -> float
> > This argument cannot be applied without label
> 
> doesn't work.

Indeed: the new rule is that if you pass n unlabelled arguments, and
there are exactly n non-optional argument to your function, this is
acceptable, but in all other cases you get the strict labelled
behaviour. So as soon as you write a label you must write them all.

A rule which would allow to mix labelled and unlabelled arguments in
an application could be extremely confusing. Consider for instance
val f : ~a:float -> ?a:float -> float -> float
# f ~a:1.0 2.0 3.0;;
What is the meaning of the above application?
If we apply the labelled rule, we get 1.0 for the first, then 2.0 for
the third (erasing the second), and 3.0 fails as an extra argument.
If we apply a new mixed unlabelled rule, we get 2.0 for the first, 1.0
for the second, and 3.0 for the third.
So we should probably refuse such an application.
But then how could we accept
# f 2.0 ~a:1.0 3.0;;
which is only a permutation of the previous one, and we expect such
labelled permutations of arguments to be always valid?

> I'd like to be able to use ~b and ~c for interface
> documentation, but not be forced to use them, and have ?a be an
> optional parameter.  This
> 
> > # f ~a:2.0 ~b:2.0 ~c:4.0;;
> > - : float = 16.
> 
> works, of course, but it's really verbose.

You can write

# (f ~a:2.0) 2.0 4.0;;

The parenthesis creates staged applications, one labelled-style and
the other unlabelled-style.

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
-------------------
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

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

[Chris Hecker]

>val f : ~a:float -> ?a:float -> float -> float

Why would this even be legal?  Is there some reason to allow multiple 
labels with the same name?  Is there a problem with the behavior I want 
without duplicate labels?

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

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

[Jacques Garrigue]

From: Chris Hecker <checker@d6.com>
> >val f : ~a:float -> ?a:float -> float -> float
> 
> Why would this even be legal?  Is there some reason to allow multiple 
> labels with the same name?

There is a good reason to have it legal: there is no way to make it
illegal.

Suppose you have a polymorphic function:
val g : f:'a -> a:int -> 'a
# g ~f:(fun ~a -> not a);;
- : a:int -> a:bool -> bool

As long as we use normal type variables for function results, we must
allow it.

> Is there a problem with the behavior I want without duplicate labels?

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?

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

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

[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".  But, that's a lose 
too, since optional arguments are very useful.  Plus, the ambiguity 
wouldn't come up very often, so overall it's an intuitive win as well.

How hard would it be to implement this rule?

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

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

[Jacques Garrigue]

From: Chris Hecker <checker@d6.com>
> >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

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

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

There, that sounds better/worse, doesn't it?  :)

>A fully symmetric definition is much harder to obtain, and to
>implement.

If it's really hard to make it symmetric, then I wouldn't bother.  It's not 
worth it if it doesn't "just work" in all cases (except cases with 
duplicate labels).

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

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

[Jacques Garrigue]

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

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

[Chris Hecker]

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

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

[Alessandro Baretta]

Jacques Garrigue wrote:

> You can write
> 
> # (f ~a:2.0) 2.0 4.0;;
> 
> The parenthesis creates staged applications, one labelled-style and
> the other unlabelled-style.

Is this only type-checking stuff, or does it impact 
code-generation? Namely, does this build a new closure for 
(f ~a:2.0) and then apply it to 2.0 and 4.0, or does it 
recognize that this is a direct invocation of f, thus 
skipping the closure creation?

This might be a relevant issue for inner loops, so I thought 
I might ask.

Alex

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