[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Alternative formulations of keywords
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:
> 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 <email@example.com>