Re: Another option for closing variables

[Sergey Kovalev <kovserg33@...>]

вт, 16 июл. 2019 г. в 10:46, pocomane <pocomane_7a@pocomane.com>:
>
> > You can not write "local <const> a,b"
>
> With the last commits, you can write, for example:
>
> local <const> a, b = 1, 2
> https://github.com/lua/lua/commit/f6aab3ec1f111cd8d968bdcb7ca800e93b819d24
I see here only this:
/* stat -> LOCAL ATTRIB NAME {',' ATTRIB NAME} ['=' explist] */
local <const> x, <const> k3_78_4 = 10, k3_78 / 4

So if you intend to define long list for example of jvm opcodes or
some flags you have to write local <const> FLAG1, <const> FLAG2 =
0x100,0x200
And how you will store such constants in object
vm.opcodes={ op1=10, op2=20 } -- ?? local<const>
vm.opcodes.op3=30 -- ?? local<const>

Constant attribute is not real constant type or it's modificator. It
is only compiler annotation for local variable/upvalue.

> Constant propagation is exactly what makes compile time constants
> better than runtime ones. As Roberto said [1]:
> > Local constant variables initialized with compile-time constants are optimized away from the code.
>
> (I did not look at code, however I performed some test, and it seems
> to me that constant upvalues are optimized away too).
This is very good but still there is no way how to pass them into
functions or classes (table with metatables)
This syntax expects only local use of this restriction. If
implementation is efficient but solution is so limited why we need it?

If you want ability to control code synthesis process it should be
done explicitly. Code synthesis and compilation should be separated.
Code transformation and rule checking should be done as script to have
control over code generation before and after compilation stage.
But pushing all into compiler will result only in complexity grow.