Re: [proposal] a new keyword : final

[Eike Decker <zet23t@...>]

Though it would make really a lot of sense in case of for-loops if the
compiler would complain about assignments to variables belonging to
that for-loop, I believe that this kind of code syntax is not of much
use: the scope of local variables doesn't extend beyond a single file
anyway and usually, the scope is limited to a couple of lines. The
defensive programming style is to my knowledge usually used to make a
clear statement to other programmers using your code as a library, on
what is constant.
Unless you expect 3rd party programmers (not teammates) to modify your
code (which is really unlikely in case of modules for example), the
"final" keyword would be quite useless due to its natural limitation
to one file.

Additionally, I can only think of a few cases where it might prevent
some programming errors, but actually, I can't recall any incident
where I "accidentally" modified a variable where I expected it to be
constant, less the case even for local variables.

So I come to believe that such a keyword has a limited range of use
and would be quite superfluous. I doubt that there could be noticeable
(!) speed improvements, even if the compiler could gain some knowledge
here. The only win that I could see would be to incooperate the values
of the final variables into the bytecode to avoid value lookups, but
this would be impossible since the value of the finals are not known
at compiletime, at least for the majority of cases. Therefore it would
be still a variable value lookup which would be identical to a local
variable value lookup during execution. Variables that are "final" are
usually more useful in case of multithreaded code execution, since the
compiler knows that no locking is required when accessing these
variable values. But this is useless in Lua due to the lack of
threading in this area.

If I had a local variable that is not ought to be changed, I would
capitalize the word or something like that - my teammates would know
this of course. I don't see a real need for a keyword that complicates
the language and the compiler without a reasonable gain.

Lua has a really small amount of keywords - and that's good. Unless
there's a suggestion for a keyword which use would be orthogonal to
existing features, I would like to keep it that way. However, you can
use Metalua[1] to do exactly what you've been requesting.

Greetings,
Eike

[1] http://metalua.luaforge.net/

2010/3/22 François Perrad <francois.perrad@gadz.org>:
> The keyword 'final' is a specialization of the keyword 'local'.
> The goal is the defensive programming.
> There are 2 new grammar rules :
>    stat -> FINAL FUNCTION NAME body
>    stat -> FINAL NAME {`,' NAME} `=' explist1
> Only the parser is modified and produces new errors.
> The VM is not modified (The goal is not the performance optimization).
> This proposal has not equivalent in http://lua-users.org/wiki/ImmutableObjects.
>
> final a = 2
> a = 3           --> error : assign a final variable
>
> final c         --> error : '=' expected near 'final'
>
> final t = {}
> t.a = 1         --> ok
> t = {}          --> error : assign a final variable
>
> The first use cases are internal :
> 1) currently, the effect of an assignment of a 'for' control variable
> is unpredictable (see PiL). These control variables could marked as final.
> 2) the implicit argument 'self' of a method could be marked as final.
>
> This new keyword could easily be back ported to old version as a simple alias
> of the keyword 'local'.
>
> François Perrad
>
> Note: all attached patches are based on Lua 5.1.4
>