Re: Help with recursive destructive function

[Michael Heerdegen]

Eric Abrahamsen <address@hidden> writes:

> [...]
> That only worked for consp values. I don't understand this: `nth' is
> implemented in C as (car (nthcdr)), and nthcdr looks to me like it's
> producing a chunk of the underlying list structure. So does car of
> nthcdr return a simple value (ie something un-setf-able)

Yes, setf'able are only (some) expressions (the "place expressions"),
not plain values.  If you evaluate a (place) expression (functions
evaluate their arguments), you loose the connection to the place.
That's why `setf', `cl-callf', `pop' e.a. are necessarily macros.

(A suggesting analogy with quantum states that collapse when measured:
places collapse to values when passed to a function.)

> if car is an atom, but something still connected to the original list
> structure (setf-able) if car is a cons cell?

No, it's still not setf-able (try to replace the cons with an integer,
for example).  It's only that the original list and this cons share data
(like so often in Lisp), so if you setf the car of this cons, the
content of the original list is also altered.  If the car of this cons
was a string, and you use a destructive string operation on it, the
original list also "changes" (in this sense).  Nothing special about
setf here.

> If that's the case, I'm not sure how to reliably pass a settable value
> in to `deep-edit'. We could pass gv-refs into `deep-edit',

That would also be my first naive idea.

> In which case it would have to check values to see if they're already
> references or not (or gv-ref itself could do that check).

It's easy to change the function to accept gv-refs instead of values,
since it already uses them internally.  But AFAIK there is no test if
some value is a `gv-ref'.  Do you need deep-edit to also accept plain
values?  Then you could just pass values V as (list :value V) to make
the cases distinguishable.


Regards,

Michael.