From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Troy Hinckley Newsgroups: gmane.emacs.devel Subject: macroexpand and bytecomp.el Date: Fri, 9 Feb 2024 12:32:41 -0600 Message-ID: <723bc16c-a73c-45a7-9362-99056261d932@Spark> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="65c66fcf_415a7db8_2cf" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33922"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 09 19:33:45 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rYVh2-0008ap-Ty for ged-emacs-devel@m.gmane-mx.org; Fri, 09 Feb 2024 19:33:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rYVgN-0004XH-Os; Fri, 09 Feb 2024 13:33:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rYVgI-0004X0-4y for emacs-devel@gnu.org; Fri, 09 Feb 2024 13:32:58 -0500 Original-Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rYVgE-0005T0-PE for emacs-devel@gnu.org; Fri, 09 Feb 2024 13:32:57 -0500 Original-Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-218642337c9so697744fac.3 for ; Fri, 09 Feb 2024 10:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707503572; x=1708108372; darn=gnu.org; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=jGaenUfh9G1yLC3i9G+MoND7pbRjzAg7PCxErq0oueE=; b=El9PTezQO4Ju4LJz1i6NQUkTI3enOWi6SAbvJXq22zurg8a6x3of8sR3HnCgmzK1DH eikGOgrXDS8PazbhTh7U7ctZDdD+iDJYo4E6FEhFsKGva7wAnufn1o/8ki2P9Yi1qs5D BtV28x4NrLWNGprV5bzvar0QuE369I1B6Jgf/HeOx4E7FUdr4oFGVNOW0dU6CbVPAnuE wSsp5jAVkwen7cb+Z8pvYqEQtoGFM0ULFjqp1RF0iOKtLh9+RRT+fEixRn6oJ3sT7G0m 0cXHgTodQO5Z1A8hZJl9f8lsJRk3xjOk7vTX0GWxT/YzLSVFpd68STQjxc4sq2nVgA4E Wyew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707503572; x=1708108372; h=mime-version:subject:references:in-reply-to:message-id:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jGaenUfh9G1yLC3i9G+MoND7pbRjzAg7PCxErq0oueE=; b=DSXOLPn9bQwdTT8ZepgWyl8u60n1l42xqueZBwubqYdH1bIiiWQbHdRd2UyNTH5fnr bAjeg8YzcH5rHHNBnf4Oxra47O+jCilXexrUTDiplffRWvLOOmCA9YBN6Q949Vto4eUG splvTubertVD60FYTe5VK3yp2CGhnsKzbmHyGnm9r7DZIulAT3CCGBmmKRgzluzLmHPL A98ZT42QDEPsf2DaXPkKZbVwlmxeTFKTxSRzPFj+iCbmI2qIyQj2YTRaemT6hcpUldbx OR9IJRQVHn38GW5PI7rVg0a+3Kd7ZC6+FPf85vAzu+KxMec0gA3E516OVxMrlSxCtlFn 7GCA== X-Gm-Message-State: AOJu0YwgRKhndd9B7TQq2+tQ6epBaQQEh4eLg0kQckPgcHVBmh5N+XZV 2PETOw63zGsV4zFuP1lXjrVrwxDjfQmF34KwdCSQ43ZO1OEKvHTZnAJ6EKN/ X-Google-Smtp-Source: AGHT+IG5o0NumybUr466L/m5pdrRr+GUFElL0NVAvlzlBDHYLFz7+gKx76Hnif0onT8YXSxQ/Viemg== X-Received: by 2002:a05:6870:4509:b0:219:6e95:ba2 with SMTP id e9-20020a056870450900b002196e950ba2mr66742oao.13.1707503570785; Fri, 09 Feb 2024 10:32:50 -0800 (PST) Original-Received: from [192.168.1.203] (149-76-168-70.fidnet.com. [149.76.168.70]) by smtp.gmail.com with ESMTPSA id s18-20020a9d7592000000b006e13a9ff830sm390464otk.53.2024.02.09.10.32.49 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Feb 2024 10:32:50 -0800 (PST) In-Reply-To: X-Readdle-Message-ID: 723bc16c-a73c-45a7-9362-99056261d932@Spark Received-SPF: pass client-ip=2001:4860:4864:20::35; envelope-from=troyhinckley@gmail.com; helo=mail-oa1-x35.google.com X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 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, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316074 Archived-At: --65c66fcf_415a7db8_2cf Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have a question about how macro-expansion is handled in bytecomp.el. Th= ere are=C2=A0two variables=C2=A0byte-code-vector and byte-stack+-info in = bytecomp.el. They are populated by calls to=C2=A0byte-defop=C2=A0which wi= ll store the values in the=C2=A0tmp-compile-time-value=C2=A0property. Aft= er this, the variables are populated by a call to the=C2=A0byte-extrude-b= yte-code-vectors=C2=A0macro: (defmacro byte-extrude-byte-code-vectors () =C2=A0(prog1 (list 'setq 'byte-code-vector =C2=A0(get 'byte-code-vector 'tmp-compile-time-value) =C2=A0'byte-stack+-info =C2=A0(get 'byte-stack+-info 'tmp-compile-time-value)) =C2=A0(put 'byte-code-vector 'tmp-compile-time-value nil) =C2=A0(put 'byte-stack+-info 'tmp-compile-time-value nil))) However I don=E2=80=99t see how this would work with macro expansion. Eag= er macro expansion=C2=A0is enabled once internal-macroexpand-for-load=C2=A0= is defined in macroexp.el (which should be before bytecomp.el is loaded).= In lread.c the function load will call readevalloop which calls=C2=A0rea= devalloop=5Feager=5Fexpand=5Feval. That function will call internal-macro= expand-for-load at least twice.=C2=A0=46irst time=C2=A0it will only expan= d the top level form, and then if that is not a progn form it will=C2=A0c= all it again=C2=A0to expand all forms. However I don=E2=80=99t understand= how this would work with byte-extrude-byte-code-vectors. When that macro= is called it will set the tmp-compile-time-value properties to nil, mean= ing that when the macro is called again byte-code-vector and byte-stack+-= info will be set to nil as well. I can see that happen if I load this dummy file (defvar tmp-var =5B1 2 3=5D) (defvar my-var nil) (defmacro my-extrude () =C2=A0(prog1 (list 'setq 'my-var 'tmp-var) =C2=A0(setq tmp-var nil))) (my-extrude) Here my-var is set to nil. I understand why that is happening. What I don= =E2=80=99t understand is why does this work in bytecomp.el=3F Why doesn't= it have the issue with double expanded macros=3F -Troy --65c66fcf_415a7db8_2cf Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I have a question about how macro-expansion is hand= led in bytecomp.el. There are&=23160;two variables&=23160;byte-code-vector and byte-stack+-= info in bytecomp.el. They are populated by calls to&=23160;byte-defop&=23160;which will sto= re the values in the&=23160;tmp-compile-time-value&=23160;property. After this, the variabl= es are populated by a call to the&=23160;byte-extrude-byte-code-vectors&=23160;macro:
=
(defmacro byte-extrude-byte-code-vectors ()
&=23160;(prog1 (list 'setq 'byte-code-vector
&=23160;(get 'byte-code-vector 'tmp-compile-time-value)
&=23160;'byte-stack+-info
&=23160;(get 'byte-stack+-info 'tmp-compile-time-value))
&=23160;(put 'byte-code-vector 'tmp-compile-time-value nil)
&=23160;(put 'byte-stack+-info 'tmp-compile-time-value nil)))

However I don=E2=80=99t see how this would work with macro expansion. Eag= er macro expansion&=23160;is enabled = once internal-macroexpand-for-load&=23160;is defined in macroexp.el (= which should be before bytecomp.el is loaded). In lread.c the function lo= ad will call readevalloop which calls&=23160;readevalloop=5Feager=5Fexpand=5Feval. That function will call= internal-macroexpand-for-load at least twice.&=23160;=46irst time&=23160;it will only expand the top level = form, and then if that is not a progn form it will&=23160;call it again&=23160;to expand all forms. Howeve= r I don=E2=80=99t understand how this would work with byte-extrude-byte-c= ode-vectors. When that macro is called it will set the tmp-compile-time-v= alue properties to nil, meaning that when the macro is called again byte-= code-vector and byte-stack+-info will be set to nil as well.

I can see that happen if I load this dummy file

(defvar tmp-var =5B1 2 3=5D)
(defvar my-var nil)

(defmacro my-extrude ()
&=23160;(prog1 (list 'setq 'my-var 'tmp-var)
&=23160;(setq tmp-var nil)))

(my-extrude)


Here my-var is set to nil. I understand why that is happening. What I don= =E2=80=99t understand is why does this work in bytecomp.el=3F Why doesn't= it have the issue with double expanded macros=3F

-Troy
--65c66fcf_415a7db8_2cf--