From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#26624: 26.0.50; Generalized variable `buffer-local-value' does't restore local flag Date: Sun, 11 Feb 2018 17:54:02 +0000 Message-ID: References: <87zid6udys.fsf@drachen> <87mv13mim5.fsf@web.de> <87inbcwjrm.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1147dcfe1e05270564f3736f" X-Trace: blaine.gmane.org 1518371599 12113 195.159.176.226 (11 Feb 2018 17:53:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Feb 2018 17:53:19 +0000 (UTC) Cc: 26624@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 11 18:53:15 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekvoK-0002MC-8W for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Feb 2018 18:53:08 +0100 Original-Received: from localhost ([::1]:37290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ekvqK-0006mg-FO for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Feb 2018 12:55:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ekvqD-0006mC-6Z for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2018 12:55:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ekvqA-0005li-Il for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2018 12:55:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58910) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ekvqA-0005lD-Dc for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2018 12:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ekvqA-000545-14 for bug-gnu-emacs@gnu.org; Sun, 11 Feb 2018 12:55:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Feb 2018 17:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26624 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26624-submit@debbugs.gnu.org id=B26624.151837166319423 (code B ref 26624); Sun, 11 Feb 2018 17:55:01 +0000 Original-Received: (at 26624) by debbugs.gnu.org; 11 Feb 2018 17:54:23 +0000 Original-Received: from localhost ([127.0.0.1]:38574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekvpX-00053C-4e for submit@debbugs.gnu.org; Sun, 11 Feb 2018 12:54:23 -0500 Original-Received: from mail-lf0-f49.google.com ([209.85.215.49]:34396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ekvpU-00052z-Ud for 26624@debbugs.gnu.org; Sun, 11 Feb 2018 12:54:21 -0500 Original-Received: by mail-lf0-f49.google.com with SMTP id k19so17583321lfj.1 for <26624@debbugs.gnu.org>; Sun, 11 Feb 2018 09:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kbBgANKupFujrcUAKxqrdD2WfLIS0w5n/uBmLQ1kvok=; b=FxpkM5hr/Q4LcrrZOYB1qdDnTTkLJyk28blSZ4whrhYu6NzxKDh+AVajarIcyan9El na6koKoS2AxmV6vV1O8/A0A5hYvWEc0PUOdV8azn8Ii8s62S/Qjp6yvN0eOw4vGYA+Ac JPTeldmt8QdyIXhmUVOi8E0wZsqjKhVtXGm+n4BeucmVrRXOytBPLaxLMlPOpiNpxcAN v118C765frdG5b19g/4udBFSZ0nYKnkh4dybK9Q/CJ36bqoAyzmBQEhiWf8rDsrgxxiS ecKS9Y+BSDjn5qIrdUHuzQ+hI1gafdWTIfC8IVXy/6/4THQ/OHH91snMJUZbRO9CFNjY Pv0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kbBgANKupFujrcUAKxqrdD2WfLIS0w5n/uBmLQ1kvok=; b=f28THe8SGJz5S0oNs7AtrCur8PTuP29q4gcb1VfeHRQ1ThHTKExRhz9U27Mnt/XIOp VEGEhVI1QOHxgNElXNpDZBIlFdQB6pylXlay2vbl2Xsjv26OtNwhUDS+9EAGJNt6w0Qx QHrp1a5Aw6R6PyNa2udElZuzK55eSVcGmwn+50gOAk48m1NFbGpl9zGj+SlI17YNtgcx bT2Mxkk1SksYpviPwEifuEfKDxkPu7qnCAlg3Ja310L7RpAi02frCslANdUtEGdF5KSi 9i4D38kJurWqfyFVQlbUg+tpVMhBhwbToCE6sbzsDEBQAVf204KxsomrtxXswRJ2L2h/ Q0Gw== X-Gm-Message-State: APf1xPCirXK+D+rX78Wfpz4Q4KqNZSnosIXITQBQAtsBDhS5si3U2dGc 6y1/DqXCBtzf132zpQEx3K5cvHQjbMgAq2Vsae0= X-Google-Smtp-Source: AH8x225cyauCRNjG1xCMJFVBEHUvSXl0qMx1ACcnJuzfXWBQokiDY4ERD5fj/dtbzPaO5gaaLdqsBuPEES5QN4XBLqM= X-Received: by 10.25.149.143 with SMTP id x137mr6271526lfd.119.1518371654729; Sun, 11 Feb 2018 09:54:14 -0800 (PST) In-Reply-To: <87inbcwjrm.fsf@web.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:143158 Archived-At: --001a1147dcfe1e05270564f3736f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael Heerdegen schrieb am So., 4. Feb. 2018 um 22:02 Uhr: > Philipp Stephani writes: > > > #+begin_src emacs-lisp > > (setq my-alist '((x . 1))) > > (ignore (cl-letf (((alist-get 'y my-alist) 17)) my-alist)) > > my-alist > > =3D=3D> ((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 =E2=80=98throw=E2=80=99 or error, the PLACEs a= re 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. --001a1147dcfe1e05270564f3736f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Michae= l Heerdegen <michael_heerdeg= en@web.de> schrieb am So., 4. Feb. 2018 um 22:02=C2=A0Uhr:
=
Philipp Stephani <p.stephani2@gmail.com> writes:
>=C2=A0 #+begin_src emacs-lisp
>=C2=A0 (setq my-alist '((x . 1)))
>=C2=A0 (ignore (cl-letf (((alist-get 'y my-alist) 17)) my-alist)) >=C2=A0 my-alist
>=C2=A0 =3D=3D> ((y) (x . 1))
>=C2=A0 #+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 t= he
> forms supported by `cl-letf', then I think that's what we shou= ld
> do. The documentation for `cl-letf' clearly states: "On exit,= either
> normally or because of a =E2=80=98throw=E2=80=99 or error, the PLACEs = are set back to
> their original values." If it can't do that for some place fo= rm, it
> shouldn't be allowed.

But

=C2=A0 (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.=C2=A0 Th= e object
that represents the alist changes, however.=C2=A0 Is that a problem or an internal implementation detail?



Since it affects user-visible behavior= , I wouldn't classify it as internal implementation detail.
I= t 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 unb= ound variables). Rather than having `(cl-letf ((place val)) body)` expand t= o

(let ((oldval place))
=C2=A0 (setf pla= ce val)
=C2=A0 (unwind-protect body
=C2=A0 =C2=A0 (setf= place oldval)))

it should rather expand to
<= div>
(let ((old-state (internal-get-state place)))
= =C2=A0 (setf place val)
=C2=A0 (unwind-protect body
=C2= =A0 =C2=A0 (internal-reset-state place old-state)))

with suitably defined `internal-get-state` and `internal-reset-state`. Fo= r most use cases `internal-get-state` and `internal-reset-state` could just= be `identity` and `setf`, but for the cases discussed here they would cont= ain additional information.
--001a1147dcfe1e05270564f3736f--