 |
lua-l archive |
|
|
||
|
Let's step back.The way I read the original Peter Cawley's idea, reminded me of Common Lisp's "compile", "load" and "eval" times.
E.g. some stuff is only evaluated when we are reading and/or compiling the code. One has to decide whether this evaluation is preserved in the bytecode, or whether we allow for special evaluation that happens only when doing bytecode (like lisp does with "load")
I said "const" is crazy, meaning that it would divide people of what it means - should it shallow or deep freeze for example? I don't think one can take position on one or the other objectively... Even in real life it's confusing - the TV set on the shelf is constant - it does not move on the table, yet what is shown on the TV is moving picture. (TV=table, moving picture=contents). But it's confusing. Say for example "The TV is constant" - and unless you specify details (TV Set, TV Picture, etc.)
Contrast this with "compile-time" - there are already things in lua that are happening compile-time only - for example building string literals. As I was not able to access this "compile-time" only mode from lua itself, the beast I could do to use the "load-time" through "loadstring" - but not exactly the same. Also it feels foreign to lua itself, as the code has to be in quotes, rather than real code (although the only problem I see is the formatting and coloring). Lisp can do that with some quote and quasi-quote magic, because the language is homoiconic.
And then I feel, but can't back it up with anything, that indirectly introducing const in lua (for tables), begs for introduction of const for strings, or more of the opposite - mutable strings :)
And I love Lua for it's constant strings. On 3/8/2012 11:04 PM, Axel Kittenberger wrote:
const set1 = { _G }
Is an immutable table that has one non immutable entry, whatever it
is. Again, just because you have one immutable set, does not
automatically deepfreeze any of its contents.
Additionally there is a difference if you make a table immutable or if
you make a variable immtuable.
So to talk about the hypothetical syntax you use:
const set1 = { _G }
is something different than
set1 = const { _G }
Where the former is a variable that will always point to the table you
just created, while the second is an immutable table, but set1 might
be changed to point to something else instead.
I suppose you just didn't fully understand what you called "crazy by itself".
I wouldn't use the "const" keyword, however, but introduce a compact operator.