Re: [proposal] a new keyword : final

[David Manura <dm.lua@...>]

On Tue, Mar 23, 2010 at 2:27 PM, David Given wrote:
> final a = {}
> a[1] = "foo" -- is this legal?
>
> Unless it becomes utterly trivial --- that is, the const-ness applies to
> the variable only, and not the contents --- you very quickly start
> straying down the path towards a full type system...

The D language has useful contributions on the subject of const.  D
has the concept of "transitive const" [1], which would make the above
illegal.  D also differentiates "immutable" from it's weaker cousin,
"const" [2-4], which is an immutability that is only contextual
(within a "view" in database-speak).  The Lua page on const [5]
mentions these.

On Wed, Mar 24, 2010 at 1:44 PM, Frank Meier-Dörnberg wrote:
> Am 24.03.2010 16:48, schrieb Eike Decker:
>> I would see a benefit in conjunction with final functions, where the
>> keyword "final" would put up the requirement "Function without a
>> sideeffect", ...
> Insteat of "final function ..." I would prefer "functional ...", ...

D uses the keyword "pure" [6].

On Wed, Mar 24, 2010 at 11:48 AM, Eike Decker wrote:
> [final] simplifies analyzing code that is being executed in different threads.

The bottom of [1] gives some reasons for immutablity, including
parallel programming, optimization, placement of variables into ROM,
and self-documentation/checking.  Some of this might not apply to Lua
(e.g. ROM), but maybe the last would.  In terms of the last point,
I've felt that const correctness reduces refactoring errors in C++
(though it only goes so far in C++).

The question of why const has historically been a C++ thing was raised
in [7].  At times, I would prefer variables in C++ to const by
default, not by exception, to avoid littering "const" everywhere.

> While I don't see the sense in having a "final" keyword inside Lua, I
> believe that a static analysis tool for Lua (that can figure out if a
> function is a pure function[3]) code would be a worthy contribution.
> Even without a new keyword, such static code analysis could already
> being done effectively because it is possible to figure out which
> local variables are not changed anywhere and in combination with that,
> figuring out which functions are pure.

Whether a function is pure depends on a function's domain:

  function add(x,y) return x+y end
  -- pure?  depends if '+' operator for given variables is always pure

A function's domain sometimes can be determined statically and
sometimes can't.  Practically speaking, you may still need to
explicitly declare the above function as pure under it's expected
domain:

  pure function add(x,y) return x+y end

[1] http://www.digitalmars.com/d/2.0/const-faq.html
[2] http://www.digitalmars.com/d/2.0/const3.html
[3] http://bartoszmilewski.wordpress.com/2009/01/26/the-more-things-change-the-more-we-need-immutable/
[4] http://www.hans-eric.com/2008/07/30/functional-d-is-transitive-const-fundamental/
[5] http://lua-users.org/wiki/ImmutableObjects
[6] http://www.digitalmars.com/d/2.0/function.html
[7] http://stackoverflow.com/questions/1370042/why-is-const-correctness-specific-to-c