Re: In praise of globals

[Dirk Laurie <dirk.laurie@...>]

2013/4/17 Thomas Jericke <tjericke@indel.ch>:

> It is just a suggestion, I am not part of the Lua team, and I never said
> that this must be the solution. I explicitly said, it would be a nice
> solution for us.
...
> I would not be so defensive about suggestion, honestly.

If there is no opposition to a suggestion, the inference may be drawn
that people either support it or don't care. I am not being defensive,
I am actively opposing that suggestion.

Let us analyze what the suggestion entails. At present, `x=1` means:

   1. If there is a local variable called `x`, set its value to 1.
   2. Otherwise, if there is an upvalue called `x`, set its value to 1.
   3. Otherwise, set _ENV.x to 1.

The suggestion is to remove Step 3 from the language, and anybody who
does not like that can compile his own ancient version.

My point is that removing Step 3 is already possible. In fact, one
could write functions that control it on a per-variable basis in a
self-documenting way.

protect'x,y,z'     -- make global x,y,z readonly
expose'x,y,z'      -- make them writeable
protect('sin,cos,tan',math)  -- optional second argument, defaults to _ENV

Your reply when I made this point was: yes, you know, strict.lua does
that, you're basically already doing it, but you still want a change
to the language.

Why?

Backward-incompatible changes to a language can only be justified if
they bring very substantial advantages, great enough to outweigh the
disadvantages they cause. For example, a sufficiently high utility ratio
might be obtained by letting "\xFE\xFF\` at the start of a string say
something about the encoding of the rest of it, instead of just taking
it as two bytes of the string.

But to change the behaviour of an assignment statement would break a
very large proportion of working programs, and all would be achieved
is something that is already possible. I'd say the utility ratio is
not only small, it's less than 1.