Re: Help with recursive destructive function

[Eric Abrahamsen]

Eric Abrahamsen <address@hidden> writes:

> Michael Heerdegen <address@hidden> writes:
>
>> Eric Abrahamsen <address@hidden> writes:
>>
>>> 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?
>>
>> `functionp' would probably better, since it's not forbidden to be used
>> in dynamically bound Lisp.  Most place expressions will not contain
>> something functionp I think.  Using a unique tag would probably be
>> cleaner.
>
> I'm conscious of having set out to fix an annoying bug in the Gnus
> registry, then moving on to re-write most of eieio-persistent, and now
> apparently mucking about in the guts of gv-ref/gv-defer, which three
> weeks ago I didn't even know existed. Mission creep is real! Maybe we
> should be opening a separate bug report so other people can comment on
> adding a unique tag.
>
>> I'm not sure if having `gv-ref-p' would be useful, I can imagine that it
>> could, but have myself used this only once or twice.
>
> An intermediate solution could be to write a `gv-ref-p' inline that's
> only meant for use with `deep-edit'.

Also, this isn't terribly relevant but while fooling around I came upon
`cl-nsublis' in "cl-seq", which is sort of similar to what we're doing
here, except that:

- It is recursive (on car) instead of iterative.
- It destructively replaces elements based on an alist lookup: if an
  element matches an alist key, it's replaced with the alist value.

It's not quite applicable here, but I was interested to find something
so close to requirements. Tbh I don't think an alist lookup is very
useful. I suppose with an appropriate :test you could still have a
refined test, but the replacement is still a blunt instrument. Nearly
there, but not quite...