lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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