This page is part of the web mail archives of SRFI 88 from before July 7th, 2015. The new archives for SRFI 88 contain all messages, not just those from before July 7th, 2015.
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 <cowan@ccil.org>
http://www.ccil.org/~cowan