Re: Bug with unset variables

[Bart Schaefer <schaefer@brasslantern.com>]

On Thu, Nov 12, 2020 at 1:48 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> Syntax is not semantics.

Um, yes?  That was sort of my point.

>   ...  there's no previous equivalent of "typeset var".

Also my point.

> There's a third conception; a non-empty value.

Except that "unset" is not the same as having a non-empty value (I
would actually call this simply a "non-value", "empty" has nothing to
do with it), from the standpoint of internal representation.  I don't
happen to agree that they're equatable in the semantics of the
language, either, but that opinion is not relevant.

Consider this from an evolutionary standpoint.  To represent a
non-value requires a data structure that knows the name of the object
but contains metadata to the effect that the implementation must not
reveal to the interpreted program any value corresponding to that
name.  To represent an unset object merely requires that no data
structure exists, period; unset removes the name itself.

Given the latter implementation of "unset", we're now asked to declare
local scopes.  The most straightforward step without an architectural
change, is to cause the data structure to come into existence, so that
we know its name, and add metadata about its scope; but the existence
of the name implies that SOME value becomes visible to the program.
The historical precedent for the default behavior is established.

The only reason we can even have this discussion now is because in the
intervening years those architectural changes have been made and there
exists an internal representation for the properties of an invisible
"unset" name.