In article <·····················@ma2s2.mathematik.uni-karlsruhe.de>, I wrote:
The place passed in LOCF is not to be understood as '(cadr x)', but as
a pointer to the car-cell of what (cdr x) gave at the point LOCF was
evaluated [Much like the '&' operator in C], so when we do:
In article <··········@news.acns.nwu.edu> ····@merle.acns.nwu.edu (Andrew G Bachmann) wrote:
This isn't quite true. It doesn't keep a pointer to the car-cell of
what (cdr x) gave at the point LOCF was evaluated. What it does keep
is the accessor function ("cadr"), and the value of the structure
being accessed. For example:
> (setq list '(1 2 3 4 5))
(1 2 3 4 5)
> (setq loc (locf (caddr list)))
#<LOCATIVE (CADDR #:G150)>
> (location-contents loc)
3
> (push 4 (cdr list))
(4 2 3 4 5)
> list
(1 4 2 3 4 5)
> (location-contents loc)
2
Since the push destructively modified the list along the path that the
accessor function traverses, it changed where "loc" was referring to
to someplace different that the original cell.
Oh, .. err that is true. This implementation worked for me all the
time. But you must agree that it is possible to write a LOCF
implementation, which would work that way, by digging into the SETF
implementation. What happens if you say (locf (car (cddr list)))
instead?! It'll work. Anyhow I thought it would be a good idea to post
it, because it a. has the semantics SCL has (but wrong implemented),
and b. is useful for some obscure hacks. Maybe I'll do a bullet-proof
implementation?
BTW, I suppose that the Symbolics implementation dealed with real
pointers to the cells. [In the manual they said, that old way to do a
(setf location-contents) would be RPLACD!] I am just wondering, if
Common Lisp implementations could gain some speed, when offering
proper locatives. However implementing SETF would be alot easier.
Gilbert.