emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help with recursive destructive function


From: Eric Abrahamsen
Subject: Re: Help with recursive destructive function
Date: Wed, 06 Jun 2018 14:04:53 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Michael Heerdegen <address@hidden> writes:

> 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.)

Right, "places collapse to values when passed to a function". I
understood this intuitively, but was confounded by this sort of thing:

(defun my-set-car (thing)
  (setcar thing 'ferrari))

(let ((tree '(1 volvo pinto)))
  (my-set-car tree)
  tree) => (ferrari volvo pinto)

Where it sure looks like the tree has retained its identity and
integrity throughout the operation. But this is only a side-effect of
the fact that lisp re-uses structures (I think there was a bug report
not long ago about identical strings getting re-used in unexpected
ways). And all the n* functions like `nconc' and `nreverse' only act on
lists. Okay, I think this is sinking in.

[...]

>> 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.

I think this function could be useful in many situations, so I'd like to
make it fairly general -- gv-refs or values.

How would you feel about gv-ref itself doing a check?

(if (and (eq 'closure (caar place))
         (eq 'closure (cadr place)))
    place
  (gv-letplace ...etc...)

Too hacky?

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]