From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#55137: Different result when interpreted and when evaluating byte-compiled code Date: Wed, 27 Apr 2022 13:33:57 +0200 Message-ID: References: <8ddae25aa2488d550ca63e396015002e@webmail.orcon.net.nz> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000000de3805dda130cf" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8888"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55137@debbugs.gnu.org To: Phil Sainty Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 27 13:44:55 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1njg6I-0001zg-70 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Apr 2022 13:44:54 +0200 Original-Received: from localhost ([::1]:33246 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1njg6H-0007Si-1D for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Apr 2022 07:44:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44786) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njfwl-0006PN-0l for bug-gnu-emacs@gnu.org; Wed, 27 Apr 2022 07:35:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47464) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1njfwk-0001zy-OT for bug-gnu-emacs@gnu.org; Wed, 27 Apr 2022 07:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1njfwk-0008Rm-I5 for bug-gnu-emacs@gnu.org; Wed, 27 Apr 2022 07:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Apr 2022 11:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55137 X-GNU-PR-Package: emacs Original-Received: via spool by 55137-submit@debbugs.gnu.org id=B55137.165105925632415 (code B ref 55137); Wed, 27 Apr 2022 11:35:02 +0000 Original-Received: (at 55137) by debbugs.gnu.org; 27 Apr 2022 11:34:16 +0000 Original-Received: from localhost ([127.0.0.1]:41361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njfw0-0008Qk-8d for submit@debbugs.gnu.org; Wed, 27 Apr 2022 07:34:16 -0400 Original-Received: from mail-ed1-f41.google.com ([209.85.208.41]:38630) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njfvy-0008QV-63 for 55137@debbugs.gnu.org; Wed, 27 Apr 2022 07:34:14 -0400 Original-Received: by mail-ed1-f41.google.com with SMTP id z99so1587245ede.5 for <55137@debbugs.gnu.org>; Wed, 27 Apr 2022 04:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7REs5bms9mTucxIilStES9I2ywk5Gz9g6wfxU17g954=; b=E+HDzxYu78bwc9B1IIUpbaxFY3NokXcejWb9GjWjy35cjJ2ZDE+gUgo3Bk0X00wr/o EzOhpgJaOvUou9+ESa7AwX5fhfhpQg/fIHmJC64PB7Qbxtbb23WRf2l9afH2q+3Hn8Gw JO6ffXINoIFTIADf32A6r4odBrK877Ii2iH7Ww+J2w56WGINKul+E2XlmbXQ5k3r54k8 RhoGQIsy7zuAJro/OObklBkHc94IEjTUw8rg9OjVoGaEbIJLFlD6JoAr9wgFsKeernhy lg1EjSjPRBAqXR6JjEjxrrUSaH2f2As24pB20ZhJGxbIIO/901mEitSeHlsyafmwbEOL hzaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7REs5bms9mTucxIilStES9I2ywk5Gz9g6wfxU17g954=; b=VfJ6JTeMraKmrQymuD2cF4+3flhm7PWd26tbelhKqnOIG1b22mqLW8xYN8yxTC0G4O 3iVuOE5LxKrwaDjJyBKrrWQFF7aYc3LpE03YUUXhCP5F/SkkY76SwTrPikLEr0qxd2vK 9yeF70qnRBRUcJnkIQpdze/SPwohYqObkLntvl5A3uj+F+3THsVU/N8Kq5kD/oQRadAs A440I4cIGFDhTUIm/pooBrkVZEW3lSOhxDJxqyDQYhRxY6YpaLMwdp53zWfuWrqBoGY4 jYZuHKYOQUyuEqtLYYiVjjbv0FB40Cv3pB4oaqgKhnZkyQtGLe3EElVxbnBkaQ7lB6M+ VeYg== X-Gm-Message-State: AOAM532/ixuY0HGSmAoXVh3O25IWIwtCK3fSjRlhYvrnGL/fBmVLkoBt b0z29MN7rczNY6/UaP8mJzNFs+2cUYSRmNkp7Q== X-Google-Smtp-Source: ABdhPJzwEmMp3J+L/z/QPyZLnsEF2soHMp5AObeCWDmJddmLhgmPKmfBdWXGbKTMkdngM3d71/KtcNbmNRaXiPSWilM= X-Received: by 2002:aa7:d350:0:b0:425:e029:da56 with SMTP id m16-20020aa7d350000000b00425e029da56mr18312226edr.296.1651059248388; Wed, 27 Apr 2022 04:34:08 -0700 (PDT) In-Reply-To: <8ddae25aa2488d550ca63e396015002e@webmail.orcon.net.nz> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:230767 Archived-At: --00000000000000de3805dda130cf Content-Type: text/plain; charset="UTF-8" I understand what's happening, I just find this extremely confusing. Can byte-compilation not notice that there is a `defvar' form and thus count the variable as special also during compilation? > Try this: This cannot be done in the real cases where things break, because they (`iter-defun', for example) _need_ to know if the variable is special at the time macro gets expanded (they call internal helper functions that call `special-variable-p' in turn). The only workaround I'm aware of is putting `defvar' into an `eval-and-compile' form (or into a different file, as `require' implicitly does that). I consider this a workaround rather than a proper solution since it is very confusing and not even apparent to many users (pretty much to most of those who never stumbled into this issue). Also, resulting errors are not self-explanatory and can be anything, including incomprehensible and seemingly unrelated failures at runtime . Additionally, you need to know if said variable is going to be used in a macro that uses `special-variable-p' in its expansion code; in particular, you need to know the list of such macros (I currently know two related real-word examples: `iter-defun' and friends from the standard feature `generator' and `iter2-defun' and friends from library `iter2'). Normally, you don't even think about putting `defvar' into an `eval-and-compile'. As mentioned, I think that byte-compilation should be improved to mark variables as special during compilation time too, so that there is no need in `eval-and-compile'. I.e. even if this is not considered a bug, it should count as a feature request. Paul On Wed, 27 Apr 2022 at 13:20, Phil Sainty wrote: > On 2022-04-27 10:16, Paul Pogonyshev wrote: > > (defmacro is-special-as-macro () > > (special-variable-p 'special-variable)) > > This macro does not expand to code which calls `special-variable-p'. > Rather it calls `special-variable-p' at expansion time, and expands > to the return value of that call (nil or t). > > If you byte-compile your code without loading it, then your would-be > `special-variable' doesn't exist, and hence your macro was expanding > to nil rather than t. > > Try this: > > (defmacro is-special-as-macro () > '(special-variable-p 'special-variable)) > > > -Phil > > --00000000000000de3805dda130cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand what's happening, I just find this extrem= ely confusing. Can byte-compilation not notice that there is a `defvar'= form and thus count the variable as special also during compilation?
<= br>
> Try this:

This cannot be do= ne in the real cases where things break, because they (`iter-defun', fo= r example) _need_ to know if the variable is special at the time macro gets= expanded (they call internal helper functions that call `special-variable-= p' in turn).

The only workaround I'm aware= of is putting `defvar' into an `eval-and-compile' form (or into a = different file, as `require' implicitly does that). I consider this a w= orkaround rather than a proper solution since it is very confusing and not = even apparent to many users (pretty much to most of those who never stumble= d into this issue). Also, resulting errors are not self-explanatory and can= be anything, including incomprehensible and seemingly unrelated failures a= t runtime . Additionally, you need to know if said variable is going to be = used in a macro that uses `special-variable-p' in its expansion code; i= n particular, you need to know the list of such macros (I currently know tw= o related real-word examples: `iter-defun' and friends from the standar= d feature `generator' and `iter2-defun' and friends from library `i= ter2'). Normally, you don't even think about putting `defvar' i= nto an `eval-and-compile'.

As mentioned, I thi= nk that byte-compilation should be improved to mark variables as special du= ring compilation time too, so that there is no need in `eval-and-compile= 9;. I.e. even if this is not considered a bug, it should count as a feature= request.

Paul

On Wed, 27 Apr 2022 at 13:20, = Phil Sainty <psainty@orcon.net.n= z> wrote:
On 2022-04-27 10:16, Paul Pogonyshev wrote:
>=C2=A0 =C2=A0 =C2=A0(defmacro is-special-as-macro ()
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(special-variable-p 'special-variable))<= br>
This macro does not expand to code which calls `special-variable-p'. Rather it calls `special-variable-p' at expansion time, and expands
to the return value of that call (nil or t).

If you byte-compile your code without loading it, then your would-be
`special-variable' doesn't exist, and hence your macro was expandin= g
to nil rather than t.

Try this:

=C2=A0 =C2=A0 =C2=A0 (defmacro is-special-as-macro ()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 '(special-variable-p 'special-variable)= )


-Phil

--00000000000000de3805dda130cf--