Tuples are a special case of constant values. E.g.
const c = {1,2,3}
would create a constant table with three elements and associate it
with the name c. The interpreter will remember that _ENV.c for this
_ENV may not be redefined. A constant value can only be assigned
to such constant table fields.
In the meantime I have realized, thanks to some postings in this thread,that 'c', above, should be a local variable, not _ENV.c. The overhead intracing individual table fields would affect every key, but local variablesare not table entries.If now:c[2] = 1.5the interpreter would know that `c` is const and generate "attempt tochange a constant object".Similarly:a = cwould be generate "attempt to assign a constant object toa non-constant name", butconst a = cwould be OK.
I’m not sure I like this model, as I think it confuses the const property between a value and a “variable" that stores that value. What is really constant here is the value ‘{1,2,3}’, not ‘c’. The const-ness is really an extension of the type, not the binding of a value to a name. if you continue to use ‘const’ in this way you also run into problems with function arguments; what are the semantics/syntax for passing a tuple to a function? Can you do ’t = {1, 2, 3}; const c = t’; t[2]=100’ ?
Ignoring syntax for a moment, what would be better imho is something like:
function foo(x) return x end
c = const {1,2,3}— (not good syntax, as it looks like a call to function “const” with one argument, but you get the idea)
a = c
b = foo(a)
b[2] = 14— error here ‘attempt to modify constant value'
The ‘const-ness” here is bound to the value, and travels with it, regardless of its location (local variable, global variable, table field, function argument). imho this is much cleaner and more Lua-like than trying to give attributes to variables.
—Tim