From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Help with recursive destructive function Date: Wed, 06 Jun 2018 16:10:28 -0700 Message-ID: <87a7s7tst7.fsf@ericabrahamsen.net> References: <87efiqzzd2.fsf@ericabrahamsen.net> <87bmdu3mtf.fsf@web.de> <87zi1e9kju.fsf@web.de> <87o9hs3aht.fsf@ericabrahamsen.net> <87bmds9qcg.fsf@web.de> <87k1sg185t.fsf@ericabrahamsen.net> <044bdbf1-39a2-0e71-ec79-3d375d9109c8@gmail.com> <877eof1k7y.fsf@ericabrahamsen.net> <87wowe2sql.fsf@web.de> <877eoe2dma.fsf@ericabrahamsen.net> <87tvrgqnug.fsf@web.de> <87vabvbfrj.fsf@web.de> <87d0y30wkn.fsf@ericabrahamsen.net> <878t8mtiqz.fsf@web.de> <87vaayp4p8.fsf@ericabrahamsen.net> <87in6yw06e.fsf@web.de> <87wovbvd6y.fsf@ericabrahamsen.net> <877enba86p.fsf@web.de> <87vaavtvl5.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1528326725 5310 195.159.176.226 (6 Jun 2018 23:12:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 6 Jun 2018 23:12:05 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 07 01:12:01 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQhaz-0001EP-Dc for ged-emacs-devel@m.gmane.org; Thu, 07 Jun 2018 01:12:01 +0200 Original-Received: from localhost ([::1]:55011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQhd6-0005bZ-7m for ged-emacs-devel@m.gmane.org; Wed, 06 Jun 2018 19:14:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQhcW-0005bB-EN for emacs-devel@gnu.org; Wed, 06 Jun 2018 19:13:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQhcR-0008EE-DT for emacs-devel@gnu.org; Wed, 06 Jun 2018 19:13:36 -0400 Original-Received: from [195.159.176.226] (port=55841 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fQhcR-0008DW-66 for emacs-devel@gnu.org; Wed, 06 Jun 2018 19:13:31 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fQhaH-0000VN-Oi for emacs-devel@gnu.org; Thu, 07 Jun 2018 01:11:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 46 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:6+lTeVskViKLd27gVsGOr5R05IA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:226083 Archived-At: Eric Abrahamsen writes: > Michael Heerdegen writes: > >> Eric Abrahamsen 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...