Re: native compilation units

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

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
> 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



>

[-- Attachment #2: Type: text/html, Size: 2298 bytes --]