Re: In praise of globals

[Thomas Jericke <tjericke@...>]

On 04/17/2013 11:01 AM, Dirk Laurie wrote:

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.

I have no problem with your opposition, I just can't agree with your claim I am forcing anything on you, I don't. Even if I would want to, I couldn't.

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.

Or you could still make feature 3 available by compiler directive, it could even be an opt out instead of an opt in. There are many directives like this in the current Lua source already.

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?

I gave you the answer already, it is not the same thing if you do the check at runtime as if you do it at compile time.

Phillipp Janda said it very well in his example:
>>Silly example: Consider writing a plugin for "Runes of Magic" an MMORPG that can be scripted in Lua 5.1. If I want to use a third-party module for that I can dofile it (require is not available in RoM), and if the red icon flashes (assuming the module asserts on all used Lua functions), this module is not compatible with the game, and I can start looking for another one before writing any code myself. From time to time the set of available functions changes, when the developers have found another way how to write bots. It's better to find that out when loading the game and not when you are in the middle of a group of monsters.<<

Just in our case, its not a game and we aren't talking about monsters, it's a real machine with real components. And if you get stuck in the middle of a script, you will have to recover from that state, you can't just restart the program. If you ever had a paper jam in your printer you know how complicated recovery from an error state can be. I am well aware, that a dynamic language has less possibilities for compiler time checks, but I personally would like to see to have a few more in Lua then it has currently. And as I said, it could be an optional step, that you may or may not add to the Lua parser. These thing are possible as patches, but not as Lua libraries, as the Lua parser is not written in Lua, you need C to do this stuff.

Also I made a cross-compiler for our machines, so we actually often parse scripts on the desktop and download the byte-code. If the user wants to download a script to the machine and there is a compiler error, the script wont even be transferred to the machine. Instead the user will be informed that he made an error right at that point.

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.

I let it up to the Lua team to decides such things. I see the chances that they will take my suggestions as very slim, but I don't have a problem with that fact, we don't use vanilla Lua so I just add features that I need if I have the time.

As I see it, the handling of globals and modules Lua 5.2 is already a step in this direction. The core sentence is in the Lua 5.2 manual 8.2:
> Function module is deprecated. It is easy to set up a module with regular Lua code. Modules are not expected to set global variables.

Also Lua is not really a language that claims backwards compatibility to start with, at least that is how I understand Roberto on this issue. I have actually a lot of trust in the team, they made a good language for many purposes and their changes go, in my humble opinion, in the right direction.

-- 

Thomas