lua-users home
lua-l archive

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

Well I think that const is poorly used because not very clearly defined, and appeared late in languages definitions so that people were not trained enough to use it. 

Because this is a constraint introduced in these languages, this looses information because in the end it may conservatively not be used. Nonetheless a lot of language has it as you mentioned, and mutable to maintain const constrained names...

To me the most useful is to know that a method won't modify the state of an object. Knowing that a reference won't change, interests me much less than knowing that the referred object won't change. This is why I promoted obj const rather than const obj..., being a post condition.

But, as I said I expect nothing for the interpreter here, so that this const can be viewed as a documentation policy, not as an active principle of the language so that this is absolutely no constraint to use it or not. I still hope that using const, is not obfuscating...

Naming convention is a good thing, but it does not all. It is more naming interfaces/facades to objects, and you have to pay the effort of defining many interfaces. Moreover typing information is rarely disseminated in Lua code, because only variable names are given, and well type hierarchy concept is let to the user. Moreover, with a name like obj:get_something() you never know whether object is modified or not.

Finally, using a lexem is easier than using long names for variables, or using comments that, in lua forces new lines. It may help creating a lint too...

-----Original Message-----
From: [] On Behalf Of David Jones
Sent: Tuesday, June 13, 2006 12:40 PM
To: Lua list
Subject: const, was: Re: Lua 5.1.1 has been frozen

Grellier, Thierry wrote:
> Oh well, if it is time to add some suggestions.
> Just a lexer one : adding a `const´ keyword
> I know people are not really happy with adding endlessly some keywords, and that may breaks some programs already using it as a variable name... But I think this is really helpful to auto document code.
> I don't intend the interpreter to perform anything with it, but just as `;´ has been added to be immediately forgotten, this could be nice to add this to help documenting the code.
> It can then be a special kind of comment discarded by lexer so that code overhead is very limited... Or be more tightly coupled to grammar to limit risks of ambiguity with variable names...
> namelist ::= Name [`const´] {`,´ Name [`const´]}
> var ::=  Name [`const´] | prefixexp `[´ exp `]´ | prefixexp `.´ Name 
> funcbody ::= `(´ [parlist1] `)´ [`const´] block `end´

If it really is just documentation, then why not just use a comment?

function foo(x --const
    , y --const
) --const

Then there's the issue of what it means.  If 'x' is const does that mean 
that the variable x is not modifed, or does it mean that nothing 
referred to by x is modified.  If x references a table, does it mean 
that the table contents don't change?  Does it mean that the variable x 
won't be used to change the table contents; can the table be changed via 
a different variable that happens to refer to the same table (aliased).

Most of these different sorts of const are useful concepts, but using 
one keyword to try and cover them will be confusing.

My experience from other languages (C, C++, Objective C, Java, 
Smalltalk, etc) suggests that trying to add some notion of const to the 
language is detrimental.  It's rarely of use to the compiler, adds 
little or no safety barrier for programmers, is confusing, and isn't 
always helpful documentation.  I've seen grown men weep over C's const, 
and highly paid C++ professionals argue for hours over the meaning of 
const in C++.

The right place to annotate things with notions of constantness is the 
type hierarchy.  See, for example, java.awt.Raster / 
java.awt.WritableRaster (from Java's 2D api), NSDictionary / 
NSMutableDictionary (from Objective-C's foundation classes).