Re: Attributes

It can help readability to know that a local variable will not be 
updated later on.
But this is not something the programmer should need to specify.
Any editor that parses the code can infer this, and then display it in 
some suitable manner.

The <const> attribute also introduces inconsistencies.
Should function parameters be const or not, or support an attribute?
What about loop variables (numeric, generic; keys vs values)?
Should "local function f() end" be const or not?
Lua currently makes some arbitrary decisions here.
There are also sharp limits: I can restrict writing to a local variable,
but as soon as I move the variable to a table field in a refactoring, 
it becomes mutable again.
(And even a fictive "table.freeze" is not quite enough,
because it does not permit marking *individual* fields as <const>.)

I think what makes Lua so neat to program in are all the details I can 
afford *not* to think about,
all the concepts that have been unified because one is just a special 
case of the other.
We don't have a plethora of container types. We have just tables.
We don't have functions, methods, procedures, closures. We have just 
functions.

"There should be one - and preferably only one - obvious way to do it", 
says the Zen of Python.
Python unfortunately outgrew this credo.
Lua gets as close as is reasonably possible for a scripting language.

Variables that are not mutated are just a special case of variables 
that may be mutated.
Thus, in my opinion, they are already covered well enough.
(And indeed even Python, which has a feature for everything,
did not have a feature for this until type hints were introduced.)
There is no need for <const>. It becomes extremely useful as qualifier 
of a *type*
in a static type system where it can be propagated, but this is out of 
scope for Lua.
As a mere variable attribute, it makes Lua more complicated for little 
gain.

Regarding the problems <const> relates to:

As for loops, I would enshrine that the loop variable is free to be 
changed,
and decide whether changes should affect iteration or not.
Either choice is fine as long as a definitive answer is given.

As for <close>: I believe a more elegant alternative is "defer <stmt>".
"defer f:close()" reads perfectly fine and is not much more verbose 
than a <close> attribute on f.
It is also more general. For example, f could be a table field t.f, and 
it will still work as expected.
We could have some situation where we need to reset an index (into a 
table, or a string),
doing "i = i + k" followed by a "defer i = i - k".

Implementing "defer" using <close> is possible, but it is cumbersome 
and wasteful.
We need to construct dummy objects that have an appropriate __close 
metamethod set:

function deferred(f) return setmetatable({}, {__close = f}) end
-- in some other function:
local _ <close> = deferred(function() top = top - k end)

For these reasons, I think removing variable attributes, and 
introducing defer,
is worth exploring in a Lua dialect. I plan to do it myself if I find 
the time.

Cheers,
Lars


-- 
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/lua-l/O4URFT.N1N3MJS3AJF93%40gmx.de.