From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#26073: workaround Date: Thu, 28 Sep 2017 19:18:05 +0200 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c03aca86fe01b055a431732" X-Trace: blaine.gmane.org 1506619264 28055 195.159.176.226 (28 Sep 2017 17:21:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 28 Sep 2017 17:21:04 +0000 (UTC) Cc: 26073@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 28 19:20:59 2017 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 1dxcUS-00068V-Op for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Sep 2017 19:20:49 +0200 Original-Received: from localhost ([::1]:60148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxcUY-00012X-58 for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Sep 2017 13:20:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxcSo-00088V-If for bug-gnu-emacs@gnu.org; Thu, 28 Sep 2017 13:19:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxcSk-00060d-Ah for bug-gnu-emacs@gnu.org; Thu, 28 Sep 2017 13:19:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56571) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dxcSk-00060S-7J for bug-gnu-emacs@gnu.org; Thu, 28 Sep 2017 13:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dxcSj-0000Bi-TM for bug-gnu-emacs@gnu.org; Thu, 28 Sep 2017 13:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Sep 2017 17:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26073 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26073-submit@debbugs.gnu.org id=B26073.1506619094664 (code B ref 26073); Thu, 28 Sep 2017 17:19:01 +0000 Original-Received: (at 26073) by debbugs.gnu.org; 28 Sep 2017 17:18:14 +0000 Original-Received: from localhost ([127.0.0.1]:37019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxcRy-0000Ad-83 for submit@debbugs.gnu.org; Thu, 28 Sep 2017 13:18:14 -0400 Original-Received: from mail-pg0-f49.google.com ([74.125.83.49]:48669) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxcRw-0000AR-4i for 26073@debbugs.gnu.org; Thu, 28 Sep 2017 13:18:13 -0400 Original-Received: by mail-pg0-f49.google.com with SMTP id v23so1292475pgc.5 for <26073@debbugs.gnu.org>; Thu, 28 Sep 2017 10:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MuVE88IEu1Mthqn4uCnIdXLu4FYGfhoIIHJ0HlVeV2g=; b=sKoMXGoc0manu170JyVebgNGdvP8oRHUbSG9ajucyJ+OEhc+687595AmTuyOTuvb2u uif4q/kJN+gtJLHY5C2DNqDRxMWzKR3jlDckTOz94V5uuX7S9VT1fQlDS+5xBMabGvne 71o8kknCMtMmf3epZi/g1xcS/OVnQj+CFEm1zVwAxnDJcqjikF31bxR8FGUq53hsOcWQ WvANiKGfJCtC1n5Q7CUbAINJ5uIne40fKIxYREVEUhm1W6M46UAZUAbWxNNErp4NQBxu 1UQtNgkm9xtBD3ipohF6Um2/lABRt4v/zM6pXgJx0CAb8D7RHuHkI9imTOKnkdb4qBt+ W6Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MuVE88IEu1Mthqn4uCnIdXLu4FYGfhoIIHJ0HlVeV2g=; b=nJ4uzyLLD8sGAWFCfc0gLjBNjz3km2Zir33UgPWoawDvNg9gRIyea9TS50p4nt75FN Bmj2EWU3YXoKXcRLkMI1JoXJ5gj1sPgmmhs3axQygti5MgC7eYZKYGlt2mBNl5EUywxI P4QtiCvkk/NuagifJwMCTRF54oytWfn5ZEdRTKXI0T6RSv2ZPFIOdQStMLVwVw2vf395 QdusXbZ2pij6NqmhQ9f4Pj5geB8WFdD+QBCgizq5IDPiLfIiU7VmCQBdokORDvfnHhTf ZW2gdcSDDUqz2FloNZ7Aisgzw2LGEbY9dbXA8FEShgpDFYiVENaBwY7VCJY+3UVGkTk5 A20w== X-Gm-Message-State: AHPjjUi1llaXZt1rnPmSnw89GMbssA3P4A31KarGYYxLYBpU2TFVrmPX 3i2xe5WePCdXDoyNSeKNFxcXDniz8aXVusUEeQ== X-Google-Smtp-Source: AOwi7QBIBB/zOscZz/lOFXzNK76bz59+YYlYYJ6g2EMj05z+CSngU8PPb6nzIvu6WhoXFGW6QZKmpmNgIAquNxLwV3Q= X-Received: by 10.99.141.74 with SMTP id z71mr4818431pgd.407.1506619086066; Thu, 28 Sep 2017 10:18:06 -0700 (PDT) Original-Received: by 10.100.144.87 with HTTP; Thu, 28 Sep 2017 10:18:05 -0700 (PDT) In-Reply-To: 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:137540 Archived-At: --94eb2c03aca86fe01b055a431732 Content-Type: text/plain; charset="UTF-8" I frankly don't know how it should behave and whether fixing it for generators would break 'with-slots'. What I can see, however, is that generator functions with nested lambdas do not work properly. And you cannot realisctically say "don't use those", because lambdas can be just introduced by macros without you even thinking about it. And then the function unexpectedly produces wrong results without any hint of what might be wrong. Paul On 26 September 2017 at 16:38, Stefan Monnier wrote: > retitle 26073 How should cl-symbol-macrolet interact with rebindings? > thanks > > The problem here is indeed different from the one in bug#26068. > bug#26068 was clearly triggering a (known) bug in cl-symbol-macrolet. > > Here it's triggering a (known) misfeature. The source code has the > following comments about it: > > ;; CL's symbol-macrolet treats re-bindings as candidates for > ;; expansion (turning the let into a letf if needed), > contrary to > ;; Common-Lisp where such re-bindings hide the symbol-macro. > and > ;; FIXME: The behavior of CL made sense in a dynamically scoped > ;; language, but for lexical scoping, Common-Lisp's behavior > might > ;; make more sense (and indeed, CL behaves like Common-Lisp > w.r.t > ;; lexical-let), so maybe we should adjust the behavior based > on > ;; the use of lexical-binding. > > more concretely cl-symbol-macrolet implements the following semantics: > > (cl-symbol-macrolet ((x )) > ... (let ((x )) ..x..)) > => > ... (cl-letf (( )) ....) > > whereas Common-Lisp's symbol-macrolet wants the following semantics > instead: > > => ... (let ((x )) ..x..) > > As mentioned in the comment, it probably makes sense to change > cl-symbol-macrolet in lexical-binding code to follow Common-Lisp's > semantics (tho we'd want to give access to the old semantics if the user > explicitly uses cl-letf). > > Not sure what might break if we do that: the main user of > cl-symbol-macrolet outside of generator.el AFAIK is the with-slots of > eieio, so the question is whether some users of with-slots expect > a subsequent `let` binding to temporarily change the slot's value. > I just checked and it seems that no code in Emacs itself relies on this > behavior, so maybe it's "safe" to change it. > > > Stefan > --94eb2c03aca86fe01b055a431732 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I frankly don't know how it should behave and whether = fixing it for generators would break 'with-slots'. What I can see, = however, is that generator functions with nested lambdas do not work proper= ly. And you cannot realisctically say "don't use those", beca= use lambdas can be just introduced by macros without you even thinking abou= t it. And then the function unexpectedly produces wrong results without any= hint of what might be wrong.

Paul
<= /div>

On 26 Septem= ber 2017 at 16:38, Stefan Monnier <monnier@iro.umontreal.ca>= wrote:
retitle 26073 How should c= l-symbol-macrolet interact with rebindings?
thanks

The problem here is indeed different from the one in bug#26068.
bug#26068 was clearly triggering a (known) bug in cl-symbol-macrolet.

Here it's triggering a (known) misfeature.=C2=A0 The source code has th= e
following comments about it:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; CL's symbol-macrolet= treats re-bindings as candidates for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; expansion (turning the l= et into a letf if needed), contrary to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Common-Lisp where such r= e-bindings hide the symbol-macro.
and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; FIXME: The behavior of CL made= sense in a dynamically scoped
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; language, but for lexical scop= ing, Common-Lisp's behavior might
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; make more sense (and indeed, C= L behaves like Common-Lisp w.r.t
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; lexical-let), so maybe we shou= ld adjust the behavior based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; the use of lexical-binding.
more concretely cl-symbol-macrolet implements the following semantics:

=C2=A0 =C2=A0 =C2=A0 (cl-symbol-macrolet ((x <e>))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... (let ((x <foo>)) ..x..))
=C2=A0 =C2=A0 =3D>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ... (cl-letf ((<e> <foo>)) ..<e&= gt;..)

whereas Common-Lisp's symbol-macrolet wants the following semantics ins= tead:

=C2=A0 =C2=A0 =3D> ... (let ((x <foo>)) ..x..)

As mentioned in the comment, it probably makes sense to change
cl-symbol-macrolet in lexical-binding code to follow Common-Lisp's
semantics (tho we'd want to give access to the old semantics if the use= r
explicitly uses cl-letf).

Not sure what might break if we do that: the main user of
cl-symbol-macrolet outside of generator.el AFAIK is the with-slots of
eieio, so the question is whether some users of with-slots expect
a subsequent `let` binding to temporarily change the slot's value.
I just checked and it seems that no code in Emacs itself relies on this
behavior, so maybe it's "safe" to change it.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--94eb2c03aca86fe01b055a431732--