Re: Rant - Elisp terminology is deceptive

[Kelly Dean]

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? ;-)