lua-users home
lua-l archive

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

On 12-Nov-04, at 12:04 PM, Quinn Tyler Jackson wrote:

Since this would be a source-optimizer, and behave like a preprocessor,
would the addition of a new hint keyword "const" be terribly bothersome to Lua-purists? Such a keyword would make the optimizations much simpler, in
terms of flow analysis. "const" could have the traditional meaning, of
course (that is -- evaluate at instantiation and never allow assignment
after instantiation).

Figuring out whether a local is const or not ought to be easy with
a parser (at least, LuaParse can figure it out). I don't think it is
good to force programmers to express things which can be derived; all
it can do is create the opportunity for errors. (I know that there are
people who like to overspecify in order to be informed when they make
mistakes, so this is just my personal opinion.)

There is a case which interests me, at least, where flow-analysis could
reveal something which is hard to otherwise specify: single assignment
in multiple control flows. For example:

local foo
if -- some test -- then
  -- ...
  function foo(x) -- something -- end
  -- ...
  function foo(x) -- something else -- end

local function bar()
  return foo(a)

Assume that those are the only assignments to foo in the code. It is
therefore a constant upvalue within bar, which is a potential source
of optimisation (although the current VM does not support the optimisation
I have in mind, I don't think).

In this sense, I'm talking more about "single-assignment" than "const"; with Lua semantics, this is not strictly single-assignment because 'local foo'
implicitly assigns 'foo = nil'; however, if foo is not referenced before
the definitions in either control flow, that implicit assignment is irrelevant.

(And I do *not* emphatically want to get involved in the hair-splitting over
functional closures, so don't even think of it.)