 |
lua-l archive |
|
|
||
|
On 20/05/2020 16:39, Andrea wrote:
pocomane, If you introduce a new keyword "const", the following script will not workanymore in the new lua: local const = 2 print(const)Thank you! now I got it! However, there are always incompatibilities, see the corresponding section in the reference manuals of Lua 5.x. So why this incompatibility is deemed not acceptable? Even if there is the incompatibility, it seems very easy to fix. Just search the source code for "const" and change it where needed. And finally, we could check how frequent "const' is in the existing codebase, so we can estimate how much of it will be broken in case we adopt "const". It may turn out that really there is no problem with the old code because no one was using "const".
This is not so easy as it seems. This just seems easy if you think of small codebases of non-critical software owned by a single person and /NOT/ widely deployed or distributed.
Searching and modifying a whole codebase for the use of the word "const" on large codebases is not so easy to automate. And do you want to automate it, don't you? You wouldn't want to go manually searching and replacing with and editor on a gazillion files!
You may think, let's run a regex engine on the whole codebase and change every occurence of `const` into `const_`.
Well, what if `const_` was already defined? Ok, so you need to build a system that checks that the new name is not defined anywhere in your entire codebase and produce an algorithm that changes the substitute name with something not in use.
Easy? Have you thought of strings? How do you handle the word "const" appearing in strings? Oh well, just build a parser that identify Lua strings and turn off substitution inside Lua strings. And comments? Those are to be skipped too. And "doc" comments? Oh! Another complication for the parser.
Now we are ok? Aren't we? Wait! Lua is an embeddable language, so we may have a C application where Lua code is /embedded/ as /C/ strings. So we must scan C source files for strings containing Lua code, which in turn may have Lua strings inside them! Ugh!
Ok, we build such a monster code analyzer, which embeds a Lua parser, a C parser and some clever decision algorithms on when making the change.
Now, what about code generators? Lua is cool also because you can generate Lua code by splicing strings together and those strings may be compiled with "load" and become part of your running code. What if some generator ends up generating a stray "const" where it causes a syntax error when upgrading? So we must check any part of the codebase which could generate that thing. And probably this won't be so easy to automate.
And what about DSLs? An application could read lua files that use the word "const" as a function name with a syntax like this:
const "123456" const "hello!" and that file could not even have .lua extension. Can you see where this is leading? An upgrade nightmare.And even if you did all the steps right, you might miss some corner cases that will bite you in the ass two years down the road.
And think also of clients of your application. Imagine a client getting the upgraded application and suddenly their scripts don't work any longer.
And then you need lots of testing because your automated tool touched almost any file in your codebase. Would you REALLY trust an automatically modified source file without extensive testing?
Of course many pitfalls I mentioned could be solved, but this could cost LOTS of money on big projects. Money that actually brings you almost nothing, except a slightly cleaner syntax.
Lua is a mature language used standalone and especially embedded in many applications. Backward compatibility for big codebases meant to be
robust is a big deal.Like it or not Microsoft has made a fortune by maintaining compatibility with old versions of Windows (I can still run some nice tools built in 2002, meant to run under Windows98, without a glitch!).
The only thing that I do not like is that this would be a new keyword and I do not like adding too many keywords to the language. Lua is minimalistic and I like it as it is. Anyway I would prefer not to use the angle brackets <const>. "local const a = 1" or "const a = 1" is indeed cleaner and would be closer to the overall cleanliness of the language source code
Despite my long explanation above, I do value cleanliness and the new syntax doesn't sit too well with me, but I can understand why Lua Team went for it. And I'm willing to grok it just to have "const" variables.
They are, IMO, very useful to break long expressions and introduce new variables to make code more readable, without risking of introducing uninitialized/modifiable variables in the picture.
This could also open up some margin for optimizations in the future.Moreover I just trust Lua Team's judgement for the future evolution of Lua not to become a C-syntax nightmare, where ugly patches and stiches were added to the language for the sake of backward compatibility and almost never changing the language because you can't break too many old habits[1] and codebases.
Lua Team has already proven to be able make somewhat drastic choices in the past just to keep the language lean and clean, so I'm not afraid about Lua code becoming too akin to line noise. :-)
thank you very much anyway for answering my question Andrea
Cheers! -- Lorenzo[1] I do hate with a passion to remember how many and different identifiers are reserved in C: mem*, str*, *_t, everything beginning with _ and a capital, every all caps identifiers beginning with E, and what else!?!. In a modern language I just want proper namespacing facilities, not tons of conventions to avoid clashing, especially when clashing doesn't mean a clean syntax error but nasty undefined behavior!!!