Re: Rant - Elisp terminology is deceptive

[Kelly Dean <kelly@prtime.org>]

David Kastrup wrote:
> Closures nest.  Buffers don't.

If you define nesting to be a required attribute of environments, then of course, by definition, things that don't nest aren't environments. But it seems strange to define them that way. Maybe this is a basic computer science truth I just missed.

How about a language that provides only global variables? No locals of any kind. Would you say that its global ‟environment” isn't really an environment, because there's nothing to nest it in or nest in it?

For Elisp, although buffers' environments can't nest in other buffers' environments, they do nest in something (the global environment, which I guess you would call the ⌜default environment⌝), and there are environments (of closures) that can nest in them. You can have a global variable, shadowed by a buffer-local, shadowed by a closure-local.

> Closures are part of a lexical environment.  Buffers aren't.

An environment can only have one binding for a particular name, which means that if the name ⌜shift-select-mode⌝ can be bound to t in the global/default environment, to nil in a buffer-local environment, and to 'bar in a closure's environment, then those are necessarily three different environments. If there weren't, then there couldn't simultaneously be three bindings for the same name.

Even if you have only global scope and dynamic extent, not lexical scope and closures, every «let» still creates a new environment at runtime that nests both in the global environment and in every earlier «let» being evaluated, and each variable bound in an environment shadows every variable with the same name in every outer environment. Even if this is implemented by storing the current environment in place of outer ones and pushing the latter onto a stack, the effect is the same.

I think you're using ‟environment” to mean something different than I am. Maybe I'm using it wrong.

> --shift-select-mode-- is a generated symbol (with value 'bar) not in any
> way related to the global variable shift-select-mode.

It has a relationship to the global variable that a buffer-local variable also has: it shadows it.

> Again, the buffer does not provide scoping.

IIUC, you mean that lexically, a buffer-local variable is defined in the global scope. But my point is that its runtime instances aren't in the global environment; they're in buffers' environments. If there were only one environment, then there could be only one instance of the variable, meaning different buffers couldn't have different values for it.

If I do (setq-default shift-select-mode nil), and in three buffers I do
(setq-local shift-select-mode (random)), how many runtime variables do I have? Do you say I have only one or two? If so, which environment(s) is it bound in?

I say I have four, each in a separate environment.


David Kastrup wrote in a different message:
>> Look what happened when I proposed changing the names of set-default,
>> setq-default, and default-value. They're misleading,
>
> No, they aren't, but you are not willing to hear any explanation in
> conflict with your preconceptions.

Of course, this misleadingness is a matter of perception. The names are certainly misleading to me, despite your explanation. I thought everybody would perceive them as misleading, but obviously I was wrong about that, since you don't. At least Stephen and Eli only said the names are too old to change, not that they're not misleading.

If I'm just part of a minority that fails to understand that ⌜default⌝ is the most sensible term for the Emacs environment whose variables don't shadow variables in any other environment, then of course the term shouldn't be changed.

But if I'm part of a majority that fails to understand, then resistance is futile. You will be assimilated.

> I have my problems seeing how "Contents of address register" and
> "Contents of decrement register" are accurate concerning the current
> implementations.

Of course, those terms are not accurate at all now. But they used to be. That's why I said they're archaic.

> In their _archaic_ sense, those terms are not accurate.

Probably you mean the same thing I do, just phrased the opposite.

> fboundp is sort of an archaic feature of the language.

But given the feature, the name isn't archaic. If I had to choose a name today for that function, ⌜fboundp⌝ would be a fine choice. That's all I meant.

> there are regularly
> scheduled shouting events under the title of "standards committee".
>
> With regard to Emacs Lisp, we don't have such official events.

Isn't that what emacs-devel is for? ;-)