This page is part of the web mail archives of SRFI 89 from before July 7th, 2015. The new archives for SRFI 89 contain all messages, not just those from before July 7th, 2015.
On 13-Apr-06, at 11:41 PM, Alex Shinn wrote:
Felix raised a good point, which is that many Schemers, including those that regularly use keywords, feel at some level that they're a bit of a hack. Keywords are purely syntactic sugar, and add complexity to the language core. Yet we use them. Even if not in the literal sense of a self-evaluating literal with a colon stuck on one end, sooner or later most people come across a procedure with too many parameters to simply be tacked on as optional arguments. Currently there are many ways to handle this: ...
Nice analysis!
At the same time, Felix's concern is very valid. We shouldn't use keywords everywhere just because we can. Many of CL's functions take only one or two keyword arguments which could just as well be passed as an optional argument. And I think most Schemers would prefer (assoc elt ls my-equal?) to (assoc elt ls test: my-equal?) At the other extreme, SSAX and GUI interfaces clearly demand keyword API's. In the middle are interfaces like hash-tables and ports, which could be argued either way. We'll just have to fight those out :)
I also agree with you and Felix on this point. I'm not advocating the use of named optional parameters everywhere. The Gambit runtime library only uses them in three subsystems (this doesn't reduce their usefulness in libraries such as HTML generators). Good judgement and discipline are essential in programming. Like any powerful construct it is possible to ruin the readability of the code by overusing it. An analogy is possible with lambda. It is not because "lambda is a beautiful construct" that you should use it on every line of your code. This often leads to tangled code that either has many bugs or is impossible to understand. On the other hand sometimes having a lambda on every line of your code can lead to a very elegant and readable program. It all depends on the context.
Marc