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: Sun, 12 Mar 2023 01:00:12 +0100

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

> Consider this example:
>
> (require 'cl-lib)
> (defun f (map)
>   (cl-letf (((map-elt map 'a) 1))
>      map))
>
> (let ((map '(b 2)))
>   (f map)
>   map)
> => (b 2 a nil)
>
> (let ((map (make-hash-table)))
>   (f map)
>   (map-length map))
> => 1
>
>
> I would expect `f' to have no side effects, so get (b 2) and 0
> respectively in the two examples.

This is a symptom of a general limitation of `cl-letf'.  Currently you can't
rely on a "no side effect" behavior.  There are other examples like that
(`alist-get') and cases that are worse (binding `buffer-local-value' of
a variable in a buffer with no buffer local binding doesn't remove the
buffer-localness - that's one reason why that gv had been deprecated).

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

So I would close this one - unless you have some enlightening idea that
would be an obvious improvement with no downsides and backward
compatibility problems.


Thanks,

Michael.

Previous Next

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