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: Mon, 20 Jun 2022 08:14:33 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a8804505e1e00c14" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13220"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrea Corallo , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jun 20 14:18:00 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 1o3GLw-0003JC-0F for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Jun 2022 14:18:00 +0200 Original-Received: from localhost ([::1]:40268 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3GLu-0006ml-G4 for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Jun 2022 08:17:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53782) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3GIs-0004Pv-IW for emacs-devel@gnu.org; Mon, 20 Jun 2022 08:14:51 -0400 Original-Received: from mail-oi1-x234.google.com ([2607:f8b0:4864:20::234]:37639) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o3GIo-0006Hd-Uz for emacs-devel@gnu.org; Mon, 20 Jun 2022 08:14:49 -0400 Original-Received: by mail-oi1-x234.google.com with SMTP id h187so13404561oif.4 for ; Mon, 20 Jun 2022 05:14:46 -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=kcSVVJivdvKn7h/5tkQ/HgSUPTfOADODAz6zzwikkjI=; b=DfpgXKb4zn4qfuhXie0/HxSFktu8LqX5j8vWq/kJZ2Yqhcdl2XIJjAE1U/y71K/SdD klgdto7rrq6HMV5uHJIFeja+eMrUFjE8IwLp1fPqJU/3tNAbZavOb7CZNZyWYVve5XbZ nUH71Ypgl7OKlzphMN4JsYfM57jDHNgCFEKgBgc6Myb4N3KFFLeWQlz2EObKir1Tcf7D QaT+/ef+x7NlSWJvdfR+Mw3a2+Vpfajeq6lZsb6XuzeEFlDQnbc+xVBf0ek41PafKcYe NNOV+fnXTJLeMMW0XXISKXTrZUkQOgOPjCkyegX64JTDTSB6YsJEEYPk2KrFzvhoXcQq MbmQ== 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=kcSVVJivdvKn7h/5tkQ/HgSUPTfOADODAz6zzwikkjI=; b=0rHofC/VMyLYpqT5KjFzsB5h9O6Xbwhh688VWTuqFTxe40VcMf7nmlEs6yI9KN6RMW k0GCRIDryoNuFtnlQn29WH7OwZTDcx1iN34flBoEVcGBVssFmt8rDd9sROWzJzuZxx7u droNiKO3vP6AdVo2ilG0gXDyEkQ0KfY13MZtZHoThTpcfaweJ3YazHIY/pZ5fnDecOL0 TO5cAQrPMJ+/Zfr05m3d9A3olQpvcK03j4VU60F2kTIUVP1BdjtweMY7wGrGjljfwIan iny/UQPmEe3h/xkdBrtCJ+Het1vp3+e18YGhElTIN4O6PTt+HHAuwTfDubsAKjzJ2DC+ izkg== X-Gm-Message-State: AJIora+yBS2zmDyc2zlah90V4OWKYB7fa42j/+bogI3op1g4M2pJtGaK gegKPmpeWBRywCIyQajax5bxn2Z6TRptG9jWrtY= X-Google-Smtp-Source: AGRyM1tMxPBMYvydtq3Tf3lx3jZDjVo9F/7vTJbtYoQEpwMLTd6jvTtQLrRPRpCUEsYne1I99wMbXh1DmuI5+D0eEK0= X-Received: by 2002:a05:6808:1a96:b0:333:289e:713d with SMTP id bm22-20020a0568081a9600b00333289e713dmr4303340oib.247.1655727284845; Mon, 20 Jun 2022 05:14:44 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::234; envelope-from=owinebar@gmail.com; helo=mail-oi1-x234.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:291462 Archived-At: --000000000000a8804505e1e00c14 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 19, 2022, 9:39 PM Lynn Winebarger wrote: > 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). > An alternative would be to extend the semantics of symbols with two additional immutable bindings - one for constant values and another for constant functions. These would be shadowed by the mutable bindings during evaluation, then (if unset) be bound to the final value assigned to the mutable bindings when the namespace is finalized. Then, when a symbol is imported from a compile time environment, the import would be to the constant (value or function) binding, which could be shadowed by an evaluation-time variable/function. That should qualify as a consistent extension of the current semantics rather than a modification. It would be a lisp-4 instead of a lisp-2. Personally, I'd also like to have a way to define a global variable that does not modify the lexical scoping of let for that variable. Say, "defstatic" - corresponding to a variable with static global storage. I kind of hate that the semantics of "let" (or lambda parameters) are determined by the global state at evaluation time. Lynn > --000000000000a8804505e1e00c14 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:
The part that's incompatible with current semantics of symbols is im= porting that symbol as=C2=A0
an immutable symbolic reference.=C2= =A0 Not really a "variable" reference, but as a binding
of a symbol to a value in the run-time namespace (or package in CL termino= logy, although
CL did not allow any way to specify what I'm s= uggesting either, as far as I know).

An alternative would= be to extend the semantics of symbols with two additional immutable bindin= gs - one for constant values and another for constant functions.=C2=A0 Thes= e would be shadowed by the mutable bindings during evaluation, then (if uns= et) be bound to the final value assigned to the mutable bindings when the n= amespace is finalized.=C2=A0 Then, when a symbol is imported from a compile= time environment, the import would be to the constant (value or function) = binding, which could be shadowed by an evaluation-time variable/function.
That should qualify as a consistent extension of the = current semantics rather than a modification. It would be a lisp-4 instead = of a lisp-2.

Personally,= I'd also like to have a way to define a global variable that does not = modify the lexical scoping of let for that variable.=C2=A0 Say, "defst= atic" - corresponding to a variable with static global storage.=C2=A0 = I kind of hate that the semantics of "let" (or lambda parameters)= are determined by the global state at evaluation time.=C2=A0=C2=A0

Lynn

=
=

--000000000000a8804505e1e00c14--