GNU bug report logs - #62117
29.0.60; cl-letf on a map place has side-effects

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 62117 <at> debbugs.gnu.org
Subject: bug#62117: 29.0.60; cl-letf on a map place has side-effects
Date: Wed, 15 Mar 2023 03:13:57 +0100

Augusto Stoffel <arstoffel <at> gmail.com> writes:

> >> Of course it's usual to treat a nil entry and no entry as equivalent in
> >> Lisp, but this behavior can be a problem e.g. when constructing data to
> >> pass to other programs.
> >
> > I would say: if it is a problem, map.el is the wrong abstraction for
> > your case.  That's the genuine idea of map.el: that the inner structure
> > of a map doesn't matter.
>
> This is not right.  map.el doesn't abstract away the nil entries.  They
> make a difference all over, e.g. in map-length, map-do, map-empty-p...

Hmm - right, of course.

For your original recipe, it would in theory help if the implementation
of `map-put!' for hash tables would remove the entry if the set value is
nil.  But for the reason you gave, we probably don't want to do this.

Unless maybe we do the same thing that had been done for `alist-get'
and add an additional REMOVE argument to the generic functions `map-elt'
and `map-put!' (I'm afraid that a lot of people that like using
libraries such as map.el don't like using such an argument, though).

`cl-letf' would still not be smart enough to distinguish the two cases
(1) value was the default value and (2) there was no entry when
restoring the gv binding.


Michael.

Previous Next

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