Philipp Stephani <p.stephani2@gmail.com> writes:
> #+begin_src emacs-lisp
> (setq my-alist '((x . 1)))
> (ignore (cl-letf (((alist-get 'y my-alist) 17)) my-alist))
> my-alist
> ==> ((y) (x . 1))
> #+end_src
> I think we should spend significant efforts to avoid surprises. In
> this case, if it means we should remove `alist-get' as well from the
> forms supported by `cl-letf', then I think that's what we should
> do. The documentation for `cl-letf' clearly states: "On exit, either
> normally or because of a ‘throw’ or error, the PLACEs are set back to
> their original values." If it can't do that for some place form, it
> shouldn't be allowed.
But
(alist-get value my-alist)
doesn't change for any value (especially for y), so the alist, or the
`alist-get' place expressions, aren't effectively changed. The object
that represents the alist changes, however. Is that a problem or an
internal implementation detail?
Since it affects user-visible behavior, I wouldn't classify it as internal implementation detail.
It seems to me that the approach that `cl-letf` takes is too naive: binding a generalized variable is never the same as setting it and later resetting it to the previous value, not even for simple dynamic symbols (consider unbound variables). Rather than having `(cl-letf ((place val)) body)` expand to
(let ((oldval place))
(setf place val)
(unwind-protect body
(setf place oldval)))
it should rather expand to
(let ((old-state (internal-get-state place)))
(setf place val)
(unwind-protect body
(internal-reset-state place old-state)))
with suitably defined `internal-get-state` and `internal-reset-state`. For most use cases `internal-get-state` and `internal-reset-state` could just be `identity` and `setf`, but for the cases discussed here they would contain additional information.