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: native compilation units Date: Sat, 25 Jun 2022 14:12:11 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d259f905e249a09c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13777"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrea Corallo , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 25 20:13:16 2022 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 1o5AHU-0003UD-FD for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jun 2022 20:13:16 +0200 Original-Received: from localhost ([::1]:37624 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o5AHT-0001Zd-0R for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Jun 2022 14:13:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54892) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5AGf-0000ti-De for emacs-devel@gnu.org; Sat, 25 Jun 2022 14:12:25 -0400 Original-Received: from mail-oo1-xc2c.google.com ([2607:f8b0:4864:20::c2c]:47026) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o5AGd-0006NS-IR for emacs-devel@gnu.org; Sat, 25 Jun 2022 14:12:25 -0400 Original-Received: by mail-oo1-xc2c.google.com with SMTP id s1-20020a4adb81000000b00422e6bf0e92so1107746oou.13 for ; Sat, 25 Jun 2022 11:12:23 -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=6N4MPaPtcyIZGgmGdHEd/uJoZ4+G+QiaEjZOGcd5s0w=; b=QyK1cQs6ubFljjMR2ZBkAgaHfyxCelGy4XiuPxO0O9e6/ABtsPd0pE8IK+fN5D04Qk TbKGhuTm6J4fOIc0gF0T1UojkfFZsetU5PkZYMNmyR0mDoq7j8dt9hbXpDQauxMp+Ed9 so+OsQr4RY3oLcOSqVeSHC/y+qEX93409xTvdpX9rgoJfhFIoO921JZ9qN/+1RKUXegc 1tz19r8YyA2zRk47J9bvXaEVpuBp0hdrcoycsMNg+rQJjtrkzh2+JH3Dd7VDKvC/cE2x IMpSyY1Ya/wE+k4cWyAPehLKjgiV4qPGa3c20c9C2naeYb4Ig/aKzxpu6EaHhQeHY/JU KIbA== 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=6N4MPaPtcyIZGgmGdHEd/uJoZ4+G+QiaEjZOGcd5s0w=; b=PE0BHc6arF6xav2OOyJ/nqtK6yObPRKbBnXckzh33mLUiHiHyYlY5m51m19JOmnH0p 6/dCmemi68G8WBZEW+3M3a5DsPqR6P8GLlrKlk3EOX88mQ5av7d1vqGrKMZZh7Mz08nt ZwPzymRD7a/A3yqMYK0yiOxQhorAAKwi4lN5gD7thabmj88ALSBszresS8hBnFqvVG+m cOkGWGBInRgXjbn60LCERUtW8Uzbf6DLkDqC0KVfGkgKBdVoKSwu72MoS0D9DpSZxwSD 1sDQ71mOxmNzVp5vOQn95wFrud0wH6s84zPSm16nO4FZxZVPNHKknewqMcdMYwg9LKiS p/nA== X-Gm-Message-State: AJIora+53n7raHhVSG1QZzdUsVFGjt+J50MUs95zRiUm2fZQhPzZfvM+ hmNt0PurcmykjeUCxKxwYIHLu5vj5u2KKVVl1xo= X-Google-Smtp-Source: AGRyM1ti6RpZdspMSYNMASG09Y5u1BF8gTrHSmCzuhZ8jpBJncBh41fPgoxCdKtbeLOXhCST3tdznoSCq39VyPZ1Slw= X-Received: by 2002:a4a:d092:0:b0:425:6c2a:12 with SMTP id i18-20020a4ad092000000b004256c2a0012mr2506830oor.96.1656180742182; Sat, 25 Jun 2022 11:12:22 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::c2c; envelope-from=owinebar@gmail.com; helo=mail-oo1-xc2c.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: 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" Xref: news.gmane.io gmane.emacs.devel:291623 Archived-At: --000000000000d259f905e249a09c Content-Type: text/plain; charset="UTF-8" On Sun, Jun 19, 2022, 9:39 PM Lynn Winebarger wrote: > > > On Sun, Jun 19, 2022 at 7:02 PM Stefan Monnier > wrote: > >> > Currently compiling a top-level expression wrapped in >> > eval-when-compile by itself leaves no residue in the compiled output, >> >> `eval-when-compile` has 2 effects: >> >> 1- Run the code within the compiler's process. >> E.g. (eval-when-compile (require 'cl-lib)). >> This is somewhat comparable to loading a gcc plugin during >> a compilation: it affects the GCC process itself, rather than the >> code it emits. >> >> 2- It replaces the (eval-when-compile ...) thingy with the value >> returned by the evaluation of this code. So you can do (defvar >> my-str (eval-when-compile (concat "foo" "bar"))) and you know that >> the concatenation will be done during compilation. >> >> > but I would want to make the above evaluate to an object at run-time >> > where the exported symbols in the obstack are immutable. >> >> Then it wouldn't be called `eval-when-compile` because it would do >> something quite different from what `eval-when-compile` does :-) >> >> > The informal semantics of "eval-when-compile" from the elisp info file are > that > This form marks BODY to be evaluated at compile time but not when > the compiled program is loaded. The result of evaluation by the > compiler becomes a constant which appears in the compiled program. > If you load the source file, rather than compiling it, BODY is > evaluated normally. > I'm not sure what I have proposed that would be inconsistent with "the > result of evaluation > by the compiler becomes a constant which appears in the compiled program". > The exact form of that appearance in the compiled program is not specified. > For example, the byte-compile of (eval-when-compile (cl-labels ((f...) (g > ...))) > currently produces a byte-code vector in which f and g are byte-code > vectors with > shared structure. However, that representation is only one choice. > > It is inconsistent with the semantics of *symbols* as they currently > stand, as I have already admitted. > Even there, you could advance a model where it is not inconsistent. For > example, > if you view the binding of symbol to value as having two components - the > binding and the cell > holding the mutable value during the extent of the symbol as a > global/dynamically scoped variable, > then having the binding of the symbol to the final value of the cell > before the dynamic extent of the variable > terminates would be consistent. That's not how it's currently > implemented, because there is no way to > express the final compile-time environment as a value after compilation > has completed with the > current semantics. > > The part that's incompatible with current semantics of symbols is > importing that symbol as > an immutable symbolic reference. Not really a "variable" reference, but > as a binding > of a symbol to a value in the run-time namespace (or package in CL > terminology, although > CL did not allow any way to specify what I'm suggesting either, as far as > I know). > > However, that would capture the semantics of ELF shared objects with the > text and ro_data > segments loaded into memory that is in fact immutable for a userspace > program. > It looks to me like the portable dump code/format could be adapted to serve the purpose I have in mind here. What needs to be added is a way to limit the scope of the dump so only the appropriate set of objects are captured. There would probably also need to be a separate load-path for these libraries similar to the approach employed for native compiled files. It could be neat if all LISP code and constants eventually lived in some larger associated compilation units (scope-limited pdmp file), to have a residual dump at any time of the remaining live objects, most corresponding to the space of global/dynamic variables. That could in turn be used for local debugging or in actual bug reporting. Lynn --000000000000d259f905e249a09c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 19, 2022, 9:39 PM Lynn Winebarger <owinebar@gmail.com> wrote:


On Sun, Jun = 19, 2022 at 7:02 PM Stefan Monnier <monnier@iro.umontreal.ca&g= t; wrote:
> C= urrently compiling a top-level expression wrapped in
> eval-when-compile by itself leaves no residue in the compiled=C2=A0 ou= tput,

`eval-when-compile` has 2 effects:

1- Run the code within the compiler's process.
=C2=A0 =C2=A0E.g.=C2=A0 (eval-when-compile=C2=A0 (require 'cl-lib)). =C2=A0 =C2=A0This is somewhat comparable to loading a gcc plugin during
=C2=A0 =C2=A0a compilation: it affects the GCC process itself, rather than = the
=C2=A0 =C2=A0code it emits.

2- It replaces the (eval-when-compile ...) thingy with the value
=C2=A0 =C2=A0returned by the evaluation of this code.=C2=A0 So you can do (= defvar
=C2=A0 =C2=A0my-str (eval-when-compile (concat "foo" "bar&qu= ot;))) and you know that
=C2=A0 =C2=A0the concatenation will be done during compilation.

> but I would want to make the above evaluate to an object at run-time > where the exported symbols in the obstack are immutable.

Then it wouldn't be called `eval-when-compile` because it would do
something quite different from what `eval-when-compile` does :-)


The informal semantics of "eval-w= hen-compile" from the elisp info file are that=C2=A0
=C2=A0 = =C2=A0 =C2=A0This form marks BODY to be evaluated at compile time but not w= hen
=C2=A0 =C2=A0 =C2=A0the compiled program is loaded.=C2=A0 The = result of evaluation by the
=C2=A0 =C2=A0 =C2=A0compiler becomes a const= ant which appears in the compiled program.
=C2=A0 =C2=A0 =C2=A0If you lo= ad the source file, rather than compiling it, BODY is
=C2=A0 =C2=A0 =C2= =A0evaluated normally.
I'm not sure what I have proposed that w= ould be inconsistent with "the result of evaluation=C2=A0
by= the compiler becomes a constant which appears in the compiled program"= ;.
The exact form of that appearance in the compiled program is n= ot specified.
For example, the byte-compile of (eval-when-com= pile (cl-labels ((f...) (g ...)))
currently produces a byte-code = vector in which f and g are byte-code vectors with
shared structu= re.=C2=A0 However, that representation is only one choice.
<= br>
It is inconsistent with the semantics of *symbols* as they cu= rrently stand, as I have already admitted.
Even there, you could = advance a model where it is not inconsistent.=C2=A0 For example,
= if you view the binding of symbol to value as having two components - the b= inding and the cell
holding the mutable value during the ex= tent of the symbol as a global/dynamically scoped variable,
then = having the binding of the symbol to the final value of the cell before the = dynamic extent of the variable
terminates would be consistent.=C2= =A0 That's not how it's currently implemented, because there is no = way to
express the final compile-time environment as a value afte= r compilation has completed with the
current semantics.

The part that's incompatible with current semantics of = symbols is importing that symbol as=C2=A0
an immutable symbolic r= eference.=C2=A0 Not really a "variable" reference, but as a bindi= ng
of a symbol to a value in the run-time namespace (or package i= n CL terminology, although
CL did not allow any way to specify wh= at I'm suggesting either, as far as I know).

H= owever, that would capture the semantics of ELF shared objects with the tex= t and ro_data
segments loaded into memory that is in fact immutab= le for a userspace program.

It looks to me like the portable d= ump code/format could be adapted to serve the purpose I have in mind here.= =C2=A0 What needs to be added is a way to limit the scope of the dump so on= ly the appropriate set of objects are captured.
Ther= e would probably also need to be a separate load-path for these libraries s= imilar to the approach employed for native compiled files.=C2=A0=C2=A0
It could be neat if all LISP code and constants eventual= ly lived in some larger associated compilation units (scope-limited pdmp fi= le), to have a residual dump at any time of the remaining live objects, mos= t corresponding to the space of global/dynamic variables. That could in tur= n be used for local debugging or in actual bug reporting.=C2=A0=C2=A0
=

Lynn
<= br>
--000000000000d259f905e249a09c--