Eric: 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 thing. 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 pretty printing. 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 option. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
