From unknown Fri Aug 08 22:24:08 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#55137 <55137@debbugs.gnu.org> To: bug#55137 <55137@debbugs.gnu.org> Subject: Status: Different result when interpreted and when evaluating byte-compiled code Reply-To: bug#55137 <55137@debbugs.gnu.org> Date: Sat, 09 Aug 2025 05:24:08 +0000 retitle 55137 Different result when interpreted and when evaluating byte-co= mpiled code reassign 55137 emacs submitter 55137 Paul Pogonyshev severity 55137 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 18:17:01 2022 Received: (at submit) by debbugs.gnu.org; 26 Apr 2022 22:17:01 +0000 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 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 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 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 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) MIME-Version: 1.0 From: Paul Pogonyshev Date: Wed, 27 Apr 2022 00:16:42 +0200 Message-ID: Subject: Different result when interpreted and when evaluating byte-compiled code To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000d4b4ca05dd960c7f" 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-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --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-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 22:27:45 2022 Received: (at 55137) by debbugs.gnu.org; 27 Apr 2022 02:27:45 +0000 Received: from localhost ([127.0.0.1]:40842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njXP7-0000VP-KZ for submit@debbugs.gnu.org; Tue, 26 Apr 2022 22:27:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njXP5-0000VA-C4 for 55137@debbugs.gnu.org; Tue, 26 Apr 2022 22:27:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45506) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njXP0-0005qR-2a; Tue, 26 Apr 2022 22:27:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=exzYm/sr8Od7+6gLZmPMIBE8YIiH94UtBd10MOlpDvM=; b=POOFclLC1huL 2spp6FG7fXz10VeKGyJdqzOdqZc6fTX7+DIYn9sfT9aCoevzo7QrtfTIs8c6+VrULnhmPkPL4Q1II 4ZP2QMKYSn51QjJh/xGSbSguN2uMsRNztv3l70A8YX+w3sj3HD5/YQiE+JNTK4DI5IdvdvOGWCxGR CYEbotcrpe5A6MpQVLkFTTiqaGItZrELdW6F9Evx7LOapDBEhFos1WSemqSpVs0Qe4+iSDtAFvnds sMS51OnBbLX0mCwo+7qgtr2dNhXLBN8q3Ygwru4t7bWwtgQT6QSstWgTurBxhUkhfrzPRwvJK2yJo MRna3T6mxdlS8qDvHuB/4g==; Received: from [87.69.77.57] (port=1064 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njXOz-0005ME-Hf; Tue, 26 Apr 2022 22:27:37 -0400 Date: Wed, 27 Apr 2022 05:27:25 +0300 Message-Id: <83k0bbl0qa.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-Reply-To: (message from Paul Pogonyshev on Wed, 27 Apr 2022 00:16:42 +0200) Subject: Re: bug#55137: Different result when interpreted and when evaluating byte-compiled code References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55137 Cc: 55137@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Paul Pogonyshev > Date: Wed, 27 Apr 2022 00:16:42 +0200 > > I'm not absolutely sure if it is a bug or a "feature", but it is > extremely confusing. Thanks, but please tell in what version of Emacs is this, and preferably show the information about your build that's collected by "M-x report-emacs-bug". From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 05:19:36 2022 Received: (at 55137) by debbugs.gnu.org; 27 Apr 2022 09:19:36 +0000 Received: from localhost ([127.0.0.1]:41257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njdpf-0002kW-R4 for submit@debbugs.gnu.org; Wed, 27 Apr 2022 05:19:36 -0400 Received: from mail-ed1-f42.google.com ([209.85.208.42]:37855) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njdpe-0002kH-GU for 55137@debbugs.gnu.org; Wed, 27 Apr 2022 05:19:35 -0400 Received: by mail-ed1-f42.google.com with SMTP id k27so1204833edk.4 for <55137@debbugs.gnu.org>; Wed, 27 Apr 2022 02:19:34 -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=/Zp1m2IGpnpM2+kyYegAYOiX/dfo7pwn6zA56d4xMww=; b=CDg7kev2i/X2T19rjD2APQhIewFIayLVfgPs91+1mHuggARgyR9k7fY89N55GqPwUe u3Xj9EsHYmoMqIp29dx3KIC1H0+YOBfdt96HMpb+r2xnZTkcTJUgDt+EKy5K+ZLsEBQ1 T6Ru1nlBKWXdmonCp49eetEltZbpBn0z4DokjefwLFd0N6O9Hsm9d7tBAJge1Z2O5Sc9 mOrfJRXlhFTEveh8fc62JWrGPRikbbU6Dtqc3PEY/VWwYfzqT5NX0/aa/d6hAge42A/z 4VvZYgWD+0ROmWRbpXNtMv0LBtqIu3b6YPxi8FzSYnHOPh2+cz2p6H3s9R8787lUIL4D eeYA== 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=/Zp1m2IGpnpM2+kyYegAYOiX/dfo7pwn6zA56d4xMww=; b=Sp4WKGfiJQS4F0PhDnxa8oRXRpjkXPRzD1qu7vSJhRhfowoaWErGORypzx1zvw/ARX 64PFuXLJuF84nuC2OYPjws0Tb0afKc4s18zfxYnNglXZxJMmInuettg8+LUN/6NuNepR f02eO8YNn6iphARcSqAYpxGMP9bAia0B4WrLnBs2z/QRvGouYwoaKciF9TaIx4dEOqt2 +4wcoVHa6BxQB6xQtL4NcSMOQVSWiUOYEa4bkPMrCKz7kNA/uL2m2T5vAGWR+elFOve+ 7SkgPc222zuI0vkheWmBTEIrgW75dwJpCrHrOWcZxhSERO57Kdas8tAKOEHgA5K/z05Y So0g== X-Gm-Message-State: AOAM530r27GEmtBTNuFPeptD64OnKreo4kVrtKxeafMcOnqgQ8XQjzid k7i7k4by9rzke91z9uE+YyRdOzH+cUAssNrKkA== X-Google-Smtp-Source: ABdhPJyAVR9MjDsnxjerjvsaEjWoYh4GLaa228L98KfZI9HmGCXUuNF53s/2VJKqpV1XE5W2pZ0hzO/YmGvmQ4yKSiA= X-Received: by 2002:a05:6402:5191:b0:423:fa7f:f4c2 with SMTP id q17-20020a056402519100b00423fa7ff4c2mr29658993edd.9.1651051168462; Wed, 27 Apr 2022 02:19:28 -0700 (PDT) MIME-Version: 1.0 References: <83k0bbl0qa.fsf@gnu.org> In-Reply-To: <83k0bbl0qa.fsf@gnu.org> From: Paul Pogonyshev Date: Wed, 27 Apr 2022 11:19:17 +0200 Message-ID: Subject: Re: bug#55137: Different result when interpreted and when evaluating byte-compiled code To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000066fb2405dd9f4e2b" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55137 Cc: 55137@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000066fb2405dd9f4e2b Content-Type: text/plain; charset="UTF-8" Originally reproduced with 27.2. I now upgraded to 28.1. Pretty sure it is the same with master. In GNU Emacs 28.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.33, cairo version 1.16.0) of 2022-04-27 built on gonzo Repository revision: b511f5c05ced05fc7d1e403002bc5ba782879cba Repository branch: emacs-28 Windowing system distributor 'The X.Org Foundation', version 11.0.12014000 System Description: Debian GNU/Linux bookworm/sid Configured using: 'configure --with-x-toolkit=gtk2' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK2 ZLIB Important settings: value of $LC_MONETARY: de_AT.UTF-8 value of $LC_NUMERIC: ru_RU.UTF-8 value of $LC_TIME: de_DE.UTF-8 value of $LANG: en_CA.UTF-8 locale-coding-system: utf-8-unix On Wed, 27 Apr 2022 at 04:27, Eli Zaretskii wrote: > > From: Paul Pogonyshev > > Date: Wed, 27 Apr 2022 00:16:42 +0200 > > > > I'm not absolutely sure if it is a bug or a "feature", but it is > > extremely confusing. > > Thanks, but please tell in what version of Emacs is this, and > preferably show the information about your build that's collected by > "M-x report-emacs-bug". > --00000000000066fb2405dd9f4e2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Originally reproduced with 27.2. I now upgraded to 28= .1. Pretty sure it is the same with master.

In GNU Emac= s 28.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.33, cairo versio= n 1.16.0)
=C2=A0of 2022-04-27 built on gonzo
Repository revision: b51= 1f5c05ced05fc7d1e403002bc5ba782879cba
Repository branch: emacs-28
Win= dowing system distributor 'The X.Org Foundation', version 11.0.1201= 4000
System Description: Debian GNU/Linux bookworm/sid

Configured= using:
=C2=A0'configure --with-x-toolkit=3Dgtk2'

Configu= red features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ= JPEG
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUN= D
THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK2 ZLIB

Imp= ortant settings:
=C2=A0 value of $LC_MONETARY: de_AT.UTF-8
=C2=A0 val= ue of $LC_NUMERIC: ru_RU.UTF-8
=C2=A0 value of $LC_TIME: de_DE.UTF-8
= =C2=A0 value of $LANG: en_CA.UTF-8
=C2=A0 locale-coding-system: utf-8-un= ix

On Wed, 27 Apr 2022 at 04:27, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Paul Pogonyshev <pogonyshev@gmail.com>
> Date: Wed, 27 Apr 2022 00:16:42 +0200
>
> I'm not absolutely sure if it is a bug or a "feature", b= ut it is
> extremely confusing.

Thanks, but please tell in what version of Emacs is this, and
preferably show the information about your build that's collected by "M-x report-emacs-bug".
--00000000000066fb2405dd9f4e2b-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 07:20:48 2022 Received: (at 55137) by debbugs.gnu.org; 27 Apr 2022 11:20:48 +0000 Received: from localhost ([127.0.0.1]:41344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njfiy-0005vM-Ek for submit@debbugs.gnu.org; Wed, 27 Apr 2022 07:20:48 -0400 Received: from smtp-3.orcon.net.nz ([60.234.4.44]:53007) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njfiv-0005vB-2p for 55137@debbugs.gnu.org; Wed, 27 Apr 2022 07:20:46 -0400 Received: from [10.253.37.70] (port=35617 helo=webmail.orcon.net.nz) by smtp-3.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1njfir-0000Xh-TZ; Wed, 27 Apr 2022 23:20:42 +1200 Received: from ip-139-180-65-103.kinect.net.nz ([139.180.65.103]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Wed, 27 Apr 2022 23:20:41 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 27 Apr 2022 23:20:41 +1200 From: Phil Sainty To: Paul Pogonyshev Subject: Re: bug#55137: Different result when interpreted and when evaluating byte-compiled code In-Reply-To: References: Message-ID: <8ddae25aa2488d550ca63e396015002e@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55137 Cc: 55137@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 07:34:16 2022 Received: (at 55137) by debbugs.gnu.org; 27 Apr 2022 11:34:16 +0000 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 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 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) MIME-Version: 1.0 References: <8ddae25aa2488d550ca63e396015002e@webmail.orcon.net.nz> In-Reply-To: <8ddae25aa2488d550ca63e396015002e@webmail.orcon.net.nz> From: Paul Pogonyshev Date: Wed, 27 Apr 2022 13:33:57 +0200 Message-ID: Subject: Re: bug#55137: Different result when interpreted and when evaluating byte-compiled code To: Phil Sainty Content-Type: multipart/alternative; boundary="00000000000000de3805dda130cf" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55137 Cc: 55137@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --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-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 07 21:37:35 2022 Received: (at 55137) by debbugs.gnu.org; 8 Nov 2022 02:37:35 +0000 Received: from localhost ([127.0.0.1]:35898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1osEUZ-0008S2-J4 for submit@debbugs.gnu.org; Mon, 07 Nov 2022 21:37:35 -0500 Received: from mout.web.de ([212.227.15.4]:49475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1osEUX-0008Rl-Et for 55137@debbugs.gnu.org; Mon, 07 Nov 2022 21:37:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1667875038; bh=0O/s/mriZUzQErjd+0cv4UuY4F+k1ZUuIM6mYmo7WJ0=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=oe5Q4VveelTWaJG4bo16VhE7VlvLn/O8i38wIiko+MOzeWJyrkd1vyeTYfBAJR3wl oz0e2yOFMY4AVJqtUyolGjLhWVDrdybWiuJDvLAod3BhsV/AAeCOHATArET/64M5ZJ naEoZtPPkafdDN+kPey3mSVUMRD6EeP2Wl5bbfzDLHjUer+C6cjz1TNA0NRj9b0owm 8oboO4TGhzG6liST0bLjQB+u8qTNTPS4F2LeCt/xdSuMd25rj7YomgEfaNv4Ups3mD y2HTlLPWOpuiI0AlT+Lp6SyGJA5/GpXVQVS4Vm4SahnLbb0IIkY3NcoE/r0CkO8wi7 zFBWz6OpTlTJA== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from drachen.dragon ([88.66.71.129]) by smtp.web.de (mrweb006 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MnX17-1pJMF91HE5-00jZWs; Tue, 08 Nov 2022 03:37:18 +0100 From: Michael Heerdegen To: Paul Pogonyshev Subject: Re: bug#55137: Different result when interpreted and when evaluating byte-compiled code In-Reply-To: (Paul Pogonyshev's message of "Wed, 27 Apr 2022 13:33:57 +0200") References: <8ddae25aa2488d550ca63e396015002e@webmail.orcon.net.nz> Date: Tue, 08 Nov 2022 03:37:15 +0100 Message-ID: <8735aukw84.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:xQUiUHI9UegXPwMU2spSogTzpmcuYv20zV/zqVLAeoAEhYMRsDf rypRlq5gR6uE3mjDSERwGLkUiPB4GtzNBPiE56NbYaJ/Tl0rf/OdZQgtGLFLdIckbX4EELS J36xyHnugAEfqLmNBMTJW9vSUvlMP2D5k8JdX1IIhnx9OcCzKlfv8L9mlcLL0ZlTuKeadCP 4ZwircoN1/PequkgQIk+A== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:g0A3Vdb7DOk=;Q1eHIXkR/EB7AG2iYePkcFNAFeD Vdy57lwP9gsH3qRUBYcnArq0UG8D/MZWBi91fYmND8zDaizhkoP49bwZ3tI9Bt3HS3WSz8UNL 3PuKo7wjAYagATxZ8V/Oq3+JkuLXWC2wLtDDpDazsgyzms8c69I32/it6SHaqsUMNqnDuNcqx CCnkg1S3mxV5MTuvsoLl4kU6XXRe+pjDL0s4xUdkVAMXK5idbENh8ppu74P4RCa5yQokkaBMV 0s9ze84fAwH7NZZt1M6qUlX1UPWJ4A5hjp/CzI5cT0o8Ox2g/b862kLNB3BMjj21Jn2idzha6 vcwiocdRjtDHOMSc58N/M4enEkWu/3os3W9eXCUbM3Ydyx+LDx7AjA3hsf0eevCWH6kdNCd54 cusSE4OJxSMwaQyOI3xzqIZX3dl736UlpNERYgcdNftj4xVqBQPJ4EzAIhKL+UrUF3FcTl0X5 dgJR+ylf5lyE5WZ1vNQaoHEmZV17WAoFPV2nfUGMMYdnRSW+gwek+uOp9i7pEw/w3wc6rZh2M s1ZtR9F/W6P7nhTRlwXJ5Cah50DvYslV8/qIQtvJ7CXAvTYsBB+uLGHVM8ZnTV+TbuH86vc6F im5XpVh3JdU7O+9VR7KeMa5gmqfdnf8AXfOblQacvKOWfG9fRmkt+lG1XkP3USH8wYO9L0Y4+ vjPUaaen9WqLi55EtXajWhHb3FJ139moir7nAkjryPQ64XeuwB79xz3yStaFZXwe8T82VBicg 7gzRAhgu0TN9QL4Hgpm/f9OuDgvHO+tnX7oHQQOECYvVKVb8xxNp8CYY1RYGHE1/dISUgC0zA rK/ClnperH/m/wQG1wU1mMedaR4xJ0l5DvzSIXiRUpp+b25rfrLj7OclD8JrJq1WNe9QGiOVa 27rvuUIJHJcon9EiyqqZ0slbu4KWtGwUf42EnMW+Rz1sUuawOjY14ZZBl0Spjp/pwYJtaS+v4 hHrQ+Q== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55137 Cc: Phil Sainty , 55137@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Paul Pogonyshev writes: > 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). Do you have a recipe using `iter-defun' that reproduces the problem? Is it sure that this can't be fixed in generator.el? Michael.