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

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

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