On 04/17/2013 11:01 AM, Dirk Laurie wrote:
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.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.
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.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.
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.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?
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.
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.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.
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:
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.