GNU bug report logs - #47425
26.3; `plist-get', `plist-put' should accept a TEST function

Previous Next

Full log

Message #91 received at 47425 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: "47425 <at> debbugs.gnu.org" <47425 <at> debbugs.gnu.org>,
 Mattias Engdegård <mattiase <at> acm.org>,
 Nicolas Petton <nicolas <at> petton.fr>, Philipp Stephani <p.stephani2 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#47425: 26.3; `plist-get', `plist-put' should accept a TEST
 function
Date: Tue, 28 Jun 2022 17:40:10 +0200

"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:

> (let ((plist (list :a t)))
>   (setf (plist-get plist :a) nil)
>   plist)
> ;; => (:a nil)
>
> (let ((plist (list :a t)))
>   (setf (plist-get plist :a #'eq) nil)
>   plist)
> ;; error-> wrong-number-of-arguments
>
> Do we want the expander in gv.el to understand the new argument?

Yup.

> There's also the question of map.el.  Custom predicates are deprecated
> there, since they rely on knowing the underlying map type.  Do we want
> plist operations to understand custom predicates regardless?

Using the map functions for plists doesn't really work, so I don't think
it matters much.  That is, if you end up with a nil MAP after doing some
deletes, you suddenly can't put anything into the map.

I think expanding map.el to try to handle plists was a mistake -- it's a
fun hack, but can't be used meaningfully in practice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.