From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Using the content of a dynamic variable in a macro Date: Mon, 27 Feb 2023 21:44:43 -0500 Message-ID: References: <87o7pi9m9s.fsf@cassou.me> <83fsaukruu.fsf@gnu.org> <87lekm9j2v.fsf@cassou.me> <87h6v753p5.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a71b3a05f5b99401" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30559"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , Damien Cassou , Eli Zaretskii , emacs-devel To: Basil Contovounesios Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 28 03:45:49 2023 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 1pWpzx-0007oJ-7u for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Feb 2023 03:45:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pWpzB-0004ji-9d; Mon, 27 Feb 2023 21:45:01 -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 1pWpz9-0004jG-Sw for emacs-devel@gnu.org; Mon, 27 Feb 2023 21:44:59 -0500 Original-Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pWpz7-00022i-Vc; Mon, 27 Feb 2023 21:44:59 -0500 Original-Received: by mail-pj1-x1034.google.com with SMTP id m3-20020a17090ade0300b00229eec90a7fso626381pjv.0; Mon, 27 Feb 2023 18:44:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GmcZy4oL2OUfV7z2o591z7i7K3QHrCOTLl5MpAdQAaU=; b=ATJoHLCzFRZ2WgAfsN4dqgG6K7G5ky1P06oW5CZulLXyBbXOOAGP735XBgrpfv4nS0 U4tURLrKE17I9wzosl/9+69uTot/yqorUmAVsmrAuWv8auK0VKCHw6sdwRW7kn7tErvq EpuAjqbsa6/yNV0NXyvlec3217pZhxSlerCld5QDr5Dz36pQPwv/xoK7e87WrizMUo9J vxQEbklEv0CmtFjSVXbdAfzanF5Qkp4B+zG4GqYAgmN5MhtM5ed3MWiizXoEN5QYJeBm OjyAgABIm/iw6o23wGDYDqt0dSfnjZPfrKpUBzX581LAI4k2K4VTvnj4XYQvTHy1art0 5b2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GmcZy4oL2OUfV7z2o591z7i7K3QHrCOTLl5MpAdQAaU=; b=SC/BqjHZkwDEGQzqY6LtJn7jJDwEcT0rLKaiE6Cqn3EAWjvXYzy5s0moOTOLGtFK2v aVtDXujAeixz+Wtr46q62antFFKXgOYVy9/f3paklyXCZYkzqRXaJm4tX6jO0iDvEYSN cI4GA3azeXNh46YJhEpxKvck6hT/rAT9Ik3hQ4u/5P6Etj6Xtuc7hf0rZT3ttEkymkG8 tKzd0hnSE2ClopmdY6mrmMa2UIxR/jXWsDWoilsKASnTOI+e/fBniM0mgNXNQrXXnJsM ALyb1gEsNpMKgtFqS4R19pjD+KUdcWfLwvgHIuYB+JR6FOH6Ba4O2D/llekDdCIWJCcP fnQg== X-Gm-Message-State: AO0yUKWhrKx3WxKEe5HzQNOMhEUKu5/FH6Xn0xRQMHNPpJ1jFTnwepwm whcAU4K/BxCbHDLu2A5+jfOnvU6r0E+cbHKbolQ= X-Google-Smtp-Source: AK7set+su+N4nTquo+KXg1RfNzkaj+v6rV1nTJjD1oA/ZUDjoFGohecfdyZRmIRB2DWt9ZH24scDTNu+TjYn2K6qsVM= X-Received: by 2002:a17:903:230f:b0:199:21af:cb86 with SMTP id d15-20020a170903230f00b0019921afcb86mr6098179plh.4.1677552295286; Mon, 27 Feb 2023 18:44:55 -0800 (PST) In-Reply-To: <87h6v753p5.fsf@tcd.ie> Received-SPF: pass client-ip=2607:f8b0:4864:20::1034; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1034.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 autolearn=ham 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:303846 Archived-At: --000000000000a71b3a05f5b99401 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 27, 2023, 2:05 PM Basil Contovounesios wrote: > Richard Stallman [2023-02-26 22:24 -0500] wrote: > > > > Lexical binding isn't the issue - the variable is global in scope. > > > The issue is that when you explicitly run the byte-compiler in batch > mode, > > > the "defvar" expression is only compiled, not evaluated, while the > defmacro > > > is evaluated, and the application of the macro function is evaluated > during > > > compilation. > > > > Should we change this to evaluate defvar in batch mode? > > The byte-compiler avoids evaluating the defvar also in non-batch mode. > > So the question is how much of the code that it is compiling should the > byte-compiler evaluate. > > We may need to reuse or possibly extend the notions of Lisp code safety > we have before the byte-compiler can start evaluating arbitrary > expressions. I'm not sure it's worth the complexity. > I didn't word my response very precisely. I mentioned batch mode because the user was byte compiling in a separate batch process, so it seemed clearer to say that the compile time and evaluation time environments must be distinct in that case. The difference I described above happens any time a file is compiled as a unit and not evaluated. One reason to not make defvar (and defun) take effect in the compile-time environment is that newcomers to across may mistakenly believe that changing the value of a variable should be able to dynamically change the code produced by instances already loaded. In other words, believing that macro expansion can be dynamic, when in fact the result of the expansion is a constant embedded in the compiled file (modulo optimization by the byte compiler). Lynn --000000000000a71b3a05f5b99401 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 27, 2023, 2:05 PM Basil Contovounesios <contovob@t= cd.ie> wrote:
Richard Stallm= an [2023-02-26 22:24 -0500] wrote:

>=C2=A0 =C2=A0> Lexical binding isn't the issue - the variable is= global in scope.
>=C2=A0 =C2=A0> The issue is that when you explicitly run the byte-co= mpiler in batch mode,
>=C2=A0 =C2=A0> the "defvar" expression is only compiled, n= ot evaluated, while the defmacro
>=C2=A0 =C2=A0> is evaluated, and the application of the macro functi= on is evaluated during
>=C2=A0 =C2=A0> compilation.
>
> Should we change this to evaluate defvar in batch mode?

The byte-compiler avoids evaluating the defvar also in non-batch mode.

So the question is how much of the code that it is compiling should the
byte-compiler evaluate.

We may need to reuse or possibly extend the notions of Lisp code safety
we have before the byte-compiler can start evaluating arbitrary
expressions.=C2=A0 I'm not sure it's worth the complexity.

I didn= 9;t word my response very precisely.=C2=A0 I mentioned batch mode because t= he user was byte compiling in a separate batch process, so it seemed cleare= r to say that the compile time and evaluation time environments must be dis= tinct in that case.
The difference I described above= happens any time a file is compiled as a unit and not evaluated.=C2=A0=C2= =A0
One reason to not make defvar (and defun) take e= ffect in the compile-time environment is that newcomers to across may mista= kenly believe that changing the value of a variable should be able to dynam= ically change the code produced by instances already loaded.=C2=A0 In other= words, believing that macro expansion can be dynamic, when in fact the res= ult of the expansion is a constant embedded in the compiled file (modulo op= timization by the byte compiler).=C2=A0

Lynn

--000000000000a71b3a05f5b99401--