Marc Feeley scripsit:

> >What are the use cases for computed keywords?
>
> Here are a few use cases.
>
> 1) You want to write a trace facility to help show the function calls
> and returns that are performed.  On entry you want to print the
> arguments of the function and the result on exit.  So you write this
> higher order function:

[snip]

> 2) You just got hold of this nice graphics library which has many
> functions accepting named optional parameters:

Both of these will clearly work, mutatis mutandis, with my #2, since
it's easy to rewrite the second example in terms of constructing a new
a-list of arguments and then invoke it as such.

Indeed, it is more convenient to do so, since given a well-defined
representation such as an a-list, the use of keywords in procedure
calls is decoupled from the use of keywords in lambda lists: you can
use keywords to invoke any procedure that expects a a-list as its last
argument, and you can invoke any procedure expecting keywords by using
an a-list (and must do so if you are invoking it other than with the
syntax of procedure call).

> Unfortunately your students are french and don't know english too
> well so you would like to translate the keywords into french to make
> the code easier to read.

Now if you wanted this to work:

(define largeur: width:)
(rect x y largeur: 100)

then you would need computed keywords indeed.  (This would require an
extension to the SRFI such that keywords can be redefined from their
default self-values, but that's a small point.)  But as long as you
don't demand non-lexically-apparent keywords in procedure-call syntax,
you don't need computed keywords in the full CL sense.

--
Business before pleasure, if not too bloomering long before.
        --Nicholas van Rijn
                John Cowan <xxxxxx@ccil.org>
                    http://www.ccil.org/~cowan