Re: [proposal] a new keyword : final

[François Perrad <francois.perrad@...>]

2010/3/23 Eike Decker <zet23t@googlemail.com>:
> 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.

I think you talk about programming by contract.

This new keyword is useless if you see only the final program or module.
But, if you consider the coding work, it's like Unit Test :
when you don't use UT, you think that they are expensive and useless,
but when you use UT, you become addict.
Because you could refactor your code with confidence.


> 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.
>

There are different points of view :
- this keyword is not a real new feature, because if you substitute
all 'final' by 'local' in a program, its behavior is the same.
- another point of view is : 'final' introduces a support for
pure functional programming.

François

> 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
>>
>
>