GNU bug report logs - #49848
27.2.50; map-merge plist return alist

Previous Next

Full log

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, rajeev.jnk <at> sivalik.com,
 49848 <at> debbugs.gnu.org
Subject: Re: bug#49848: 27.2.50; map-merge plist return alist
Date: Wed, 04 Aug 2021 09:47:50 +0200

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

> In the specific case of merging maps into a desired type, we can simply
> be more careful in such ambiguous cases.  The attached patch does that,
> while also avoiding the quadratic lookup behaviour for lists.

I think that's the correct (and indeed only) solution here when dealing
with alist/plist ambiguities (if we don't want to say explicitly for
every map* call what the type actually is meant to be).

> (progn
>   (require 'map)
>   (map-merge-with 'list (lambda (a b) (message ">>> %s %s" a b) b)
>                   `((,(string ?a) . 1))
>                   `((,(string ?a) . 2))))
>
> In Emacs 26, it returns (("a" . 2) ("a" . 1)) without printing.
> In Emacs 27 and 28, it returns (("a" . 2)) without printing.
>
> Do we consider this a regression in Emacs 27 and try to fix it in 28
> (keeping in mind that map.el is also a GNU ELPA package)?

I think the current result value is the one that makes sense...

> Or do we drop the eql guarantee in the docstring, and call the function
> argument whenever two keys are merged, as in the attached patch?

I think that makes sense.

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