> The syntax of SRFI-177 is too heavy, and it requires to learn new > things in scheme. > > So far the arguments in favor of keywords like SRFI-177 are: > > - Performance > - Programming in the large > - Scripting > > In scripting, performance does not really matter. In programming in > the large, companies can invest in better compilers. I agree that performance is not a significant problem. It's nice if calls can be really fast, but I still haven't seen a case where keyword arguments are needed in the fast path of performance-sensitive code (graphics, etc.) They tend to be the most useful at the exported API of a module, called more rarely than the internal procedures. > That is case of for let-optionals and let-keywords (or similar > approach relying on rest arguments). This does not introduce a new > syntax, it is a good uses case for macros, it is portable, it does not > introduce new things to implement in scheme standard and the syntax is > clean. > > What precludes those macros as keywords facility and as the way-to-go > for R7RS libraries? I think I understand your argument, but I have the opposite point of view: it's macros like `let-keywords` that indicate a problem. It's similar to exception handling or object systems - while it's true that everyone can write their own system, that makes it difficult to write standard tools, and it means different codebases end up doing the same thing slightly differently. One of my favorite things about Scheme is how similar code looks in different codebases. In the case of keyword arguments, as one example documentation generators are easier to write if there's a standard way to do keyword arguments (and optional positional arguments - that's currently done with case-lambda). Compiler optimizations also become possible. SRFI 177 is approximately as portable as let-keywords; that was the big win and surprise about it. You're right that let-keywords doesn't need to be customized for each Scheme implementation, but we're talking about a very modest amount of code even with separate implementations.
