[Top][All Lists]

[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 16:10:28 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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

reply via email to

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