[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49848: 27.2.50; map-merge plist return alist
From: |
Lars Ingebrigtsen |
Subject: |
bug#49848: 27.2.50; map-merge plist return alist |
Date: |
Wed, 04 Aug 2021 09:47:50 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
"Basil L. Contovounesios" <contovob@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