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 00:16:42 +0200 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d4b4ca05dd960c7f" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3793"; mail-complaints-to="usenet@ciao.gmane.io" To: 55137@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 27 00:18:13 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 1njTVb-0000mF-Fs for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Apr 2022 00:18:11 +0200 Original-Received: from localhost ([::1]:52224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1njTVa-0006uc-1h for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Apr 2022 18:18:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36498) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njTVS-0006uU-De for bug-gnu-emacs@gnu.org; Tue, 26 Apr 2022 18:18:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46803) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1njTVS-0001Fk-0K for bug-gnu-emacs@gnu.org; Tue, 26 Apr 2022 18:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1njTVR-0002i9-Nr for bug-gnu-emacs@gnu.org; Tue, 26 Apr 2022 18:18: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: Tue, 26 Apr 2022 22:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 55137 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.165101142110340 (code B ref -1); Tue, 26 Apr 2022 22:18:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 26 Apr 2022 22:17:01 +0000 Original-Received: from localhost ([127.0.0.1]:40700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njTUT-0002gY-02 for submit@debbugs.gnu.org; Tue, 26 Apr 2022 18:17:01 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:33074) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njTUP-0002gP-T0 for submit@debbugs.gnu.org; Tue, 26 Apr 2022 18:17:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36394) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njTUP-0006s1-MZ for bug-gnu-emacs@gnu.org; Tue, 26 Apr 2022 18:16:57 -0400 Original-Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:36381) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1njTUN-0001BS-Uo for bug-gnu-emacs@gnu.org; Tue, 26 Apr 2022 18:16:57 -0400 Original-Received: by mail-ed1-x529.google.com with SMTP id a1so18388716edt.3 for ; Tue, 26 Apr 2022 15:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=o7F/mO8l0vxecJpCZTRnKkKQSCsskjPCRp6AIfbJpuI=; b=qXdp2vQh9WbIZzSkYyiPycP+nausWmoZU0Ku8cEtuFjQViLZHYGuhr6rTWDh5KqT85 641CrXO1gK1dRB1fhajCqtvxMXkhUPqD6k+nLllZcVhUzFAiuTZWOJBRO21FuHcr/jRf YgkWPVoA5AqOPQTOcTEsIH2nOqgDkwKwth82dh7Uz37oyNT0LcPTo66XJzJ/cHK8+avn VmQrkz4bwmwxLR+nk6Ww9itctqsn/5cdbm2Qgg++53bO2d1RmNnWQ71yBwzTqZln9Sjs 8Z0jJd5jU17qT2ymVrG7bBfFg2ZOkuwSQXfpQbRQJzRCQhdPbbG75u85qrUtwrXVS24B DOlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=o7F/mO8l0vxecJpCZTRnKkKQSCsskjPCRp6AIfbJpuI=; b=ZXoBkT2zxPYldTLS1U7qTtZryd/I6AFjTkVqpxAnEEhA2QbOmT8Ks49jhkks4ROcLc EUePFWKey5I1pEnMER06uZn/sLlDvZ1MyfxZ+12XUlS7AfwAkeRL0jq7Ox8g7zQs2NPX TChqYwiTPXcRj/Aw3npXJL6wQDFQM2Tb7KcH51+sn3QPq/n03BOr40uKF86pzuOoFZ75 bfQJAsv9qTJ3ZpYGJobsDCzMxQbpkciqZXcf46kggO1/jkEX4Omkl5K/5/EJOT4kSqwQ /aBQjZ1wcy8hguZWVZZnWVprphodqmIK7prue6hHNpY0YbQSlVhvRBtF+INsr7sjMYyZ fSYg== X-Gm-Message-State: AOAM533PJiehLbRz6HWYafJV+tIGbLtfY8gjgpr8weipvuv4BRc11wwZ +Gx+UMqImklQey6TpM1igEw/Ugux0jzQT6aLWRL/8QxKzIjF X-Google-Smtp-Source: ABdhPJwyN3k0L9PJakeYdQCNaPfVTwmwpQhtWZrdgUpn3jlx+zjiQMWMmkF/mHmU5J9uAsByTsjOvi6hpnsI5XmFIGY= X-Received: by 2002:a05:6402:330b:b0:425:eded:7cfe with SMTP id e11-20020a056402330b00b00425eded7cfemr11713143eda.357.1651011413651; Tue, 26 Apr 2022 15:16:53 -0700 (PDT) Received-SPF: pass client-ip=2a00:1450:4864:20::529; envelope-from=pogonyshev@gmail.com; helo=mail-ed1-x529.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:230754 Archived-At: --000000000000d4b4ca05dd960c7f Content-Type: text/plain; charset="UTF-8" I'm not absolutely sure if it is a bug or a "feature", but it is extremely confusing. To reproduce: store this as file `test.el': (defvar special-variable nil) (defmacro is-special-as-macro () (special-variable-p 'special-variable)) (defun is-special-as-function () (is-special-as-macro)) (print (is-special-as-function)) (print (eval '(is-special-as-macro))) Now, from command line: $ rm -f test.elc; emacs --batch -l test.el This loads the file as interpreted Elisp and prints `t' two times, i.e. always recognizes the variable as special. Next, byte-compile the file before loading: $ rm -f test.elc; emacs --batch --eval "(byte-compile-file \"test.el\")"; emacs --batch -l test.elc This prints `nil' and `t', i.e. variable is now considered non-special by `is-special-as-function'. From investigating `.elc' file, it is apparent that this is encoded into it as a macroexpanded constant. Note that `is-special-as-macro' still works fine, the problem appears only when it gets macroexpanded during byte-compilation. So, apparently `defvar' form is sort of "skipped without paying attention" during byte-compilation. If I put it into an `eval-and-compile' form, then macroexpansion does produce expected result. I noticed this with code using `iter2' library. When `iter2-defun' generator functions get macroexpanded during compilation, built-in `special-variable-p' is called, because for generator functions this is important to distinguish between local and dynamic variables. The example above is derived from debugging real failure. Standard `generator' package is also affected. Here is example code: ;;; -*- lexical-binding: t -*- (require 'generator) (defvar special-variable nil) (defun get-special-variable () special-variable) (iter-defun buggy () (let ((special-variable t)) (iter-yield (get-special-variable)))) (print (iter-next (buggy))) As before, save as `test.el' and execute the same two commands. Produced output is different depending on whether the file has been byte-compiled or not. Is `eval-and-compile' the proper workaround? Can things be made less confusing by noticing declared special variables during byte-compilation? Paul --000000000000d4b4ca05dd960c7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not absolutely sure if it is a bug or a "feat= ure", but it is
extremely confusing.

To reproduce: store thi= s as file `test.el':

=C2=A0 =C2=A0 (defvar special-variable nil)=

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

=C2=A0 =C2=A0 (defun= is-special-as-function ()
=C2=A0 =C2=A0 =C2=A0 (is-special-as-macro))
=C2=A0 =C2=A0 (print (is-special-as-function))
=C2=A0 =C2=A0 (prin= t (eval '(is-special-as-macro)))

Now, from command line:

= =C2=A0 =C2=A0 $ rm -f test.elc; emacs --batch -l test.el

This loads = the file as interpreted Elisp and prints `t' two times,
i.e. always = recognizes the variable as special.

Next, byte-compile the file befo= re loading:

=C2=A0 =C2=A0 $ rm -f test.elc; emacs --batch --eval &qu= ot;(byte-compile-file \"test.el\")"; emacs --batch -l test.e= lc

This prints `nil' and `t', i.e. variable is now considere= d non-special
by `is-special-as-function'.=C2=A0 From investigating = `.elc' file, it is
apparent that this is encoded into it as a macroe= xpanded constant.
Note that `is-special-as-macro' still works fine, = the problem appears
only when it gets macroexpanded during byte-compilat= ion.

So, apparently `defvar' form is sort of "skipped witho= ut paying
attention" during byte-compilation.=C2=A0 If I put it int= o an
`eval-and-compile' form, then macroexpansion does produce expec= ted
result.

I noticed this with code using `iter2' library.= =C2=A0 When `iter2-defun'
generator functions get macroexpanded duri= ng compilation, built-in
`special-variable-p' is called, because for= generator functions this
is important to distinguish between local and = dynamic variables.=C2=A0 The
example above is derived from debugging rea= l failure.

Standard `generator' package is also affected.= =C2=A0 Here is example code:

=C2=A0 =C2=A0 ;;; -*- lexical-binding: = t -*-

=C2=A0 =C2=A0 (require 'generator)

=C2=A0 =C2=A0 (d= efvar special-variable nil)

=C2=A0 =C2=A0 (defun get-special-variabl= e ()
=C2=A0 =C2=A0 =C2=A0 special-variable)

=C2=A0 =C2=A0 (iter-d= efun buggy ()
=C2=A0 =C2=A0 =C2=A0 (let ((special-variable t))
=C2=A0= =C2=A0 =C2=A0 =C2=A0 (iter-yield (get-special-variable))))

=C2=A0 = =C2=A0 (print (iter-next (buggy)))

As before, save as `test.el' = and execute the same two commands.
Produced output is different dependin= g on whether the file has been
byte-compiled or not.

Is `eval-and= -compile' the proper workaround?=C2=A0 Can things be made less
confu= sing by noticing declared special variables during
byte-compilation?
=
Paul
--000000000000d4b4ca05dd960c7f--