[bitc-dev] Syntax: keyword arguments
Jonathan S. Shapiro
shap at eros-os.com
Sat Mar 7 16:58:14 EST 2009
Thanks (again) for insightful questions.
I have gone back and forth about labeled arguments. There are several issues:
If arguments *can* be labeled, then labels become part of type. They
must match between definitions and declarations. This is a small
issue, but an important thing to remember.
In my opinion, labels mainly become useful when the number of
arguments to a procedure or constructor becomes fairly large. It is
often worthwhile, in that case, to consider refactoring the procedure,
but sometimes a procedure with a lot of arguments really is the right
One place where labels are *very* useful is in arguments that have
defaults. Idea: when an optional argument is present it is labeled,
and the argument otherwise takes on its default value. I note,
however, that default values and parametric abstraction don't seem to
interact favorably, and this begins to drag us toward the
constructors-as-initializers view. I would like to leave an option for
a future language change here, but I don't want to introduce optional
arguments right now.
> [keyword arguments make] code audit a lot easier and safer:
> set-size :: (box: Box, width: int, height: int) -> void
> set-size box: b width: w height: h
> set-size b h w // wrong, but hard to catch
> where the argument types are not all different.
This is a mis-statement. What makes audit easier is being able to see
the labels at the time the audit is occurring. That objective does not
motivate keyword arguments; what it motivates is an audit-oriented
Overall, I think that my inclination is *against* both optional
arguments and labeled arguments.
Though oddly enough, this is relevant to the curried application
discussion. Today, we have the option to adopt overloading procedures
by arity. Adopting curried application syntax implies giving up that
More information about the bitc-dev