Re: Tuples and other constant values

On Jul 8, 2015, at 11:34 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:

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 in
tracing individual table fields would affect every key, but local variables
are not table entries.

If now:

c[2] = 1.5

the interpreter would know that `c` is const and generate "attempt to
change a constant object".

Similarly:

a = c

would be generate "attempt to assign a constant object to
a non-constant name", but

const a = c

would 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