In article <37BBC23F.198EFA05@hplb.hpl.hp.com>,
Chris Dollin <kers@hplb.hpl.hp.com> wrote:
>Lieven Marchand wrote:
>>
>> richard@starburst.demon.co.uk (Richard Wendland) writes:
>>
>> > Nice. Updater functions are another nice feature I've not come across
>> > in another language.
>>
>> Common Lisp SETF expander functions
>>
>> It's indeed a nice feature.
>
>It may be a nice feature; it *isn't* the same feature.
>
>The difference is that in Common Lisp you have to write a setf-expander for
>each updater name, ie this is essentially a compile-time activity. It's
>much harder (if possible at all; my Steele is at home) to write the
>equivalent of
>
> define exhibit( f, x ); 42 -> f(x) enddefine;
>
>where the updater is determined dynamically. This matters more in Pop,
>of course, because so many more things (eg vectors, arrays, properties)
>are either functions or contrive to look like them. My own code passes
>properties as parameters all over the place; it would be gobsmackingly
>awful if I had to define umpteen setf forms to access them by the many
>different names I call those parameters!
>
At least it can be done (in a hacky manner, but there might be better ways):
(defun -> (new-value reader-function &rest reader-args)
(multiple-value-bind (vars values store-vars writer-form)
(get-setf-expansion (cons reader-function reader-args))
(progv vars values
(progv store-vars (list new-value)
(eval writer-form)))))
USER(391): (setq a '(1 2 3))
(1 2 3)
USER(392): (let ((f 'car)) (-> 7 f a))
7
USER(393): a
(7 2 3)
USER(394): (let ((f 'cdr)) (-> 7 f a))
7
USER(395): a
(7 . 7)
The above solution needs to use both PROGV and EVAL,
indicators of probably questionable code. In this case I suppose
it only proves your point about SETF being a compile-time activity.
The original intent of GET-SETF-EXPANSION probably was for compile-time use,
strong constructs like PROGV and EVAL are needed to abuse it
for more dynamic access.
Bernhard
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence bernhard@ai.univie.ac.at
|