Re: source-code optimizer (was RE: I'm totally baffled.)

[Rici Lake <lua@...>]

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
 else
  -- ...
  function foo(x) -- something else -- end
end

local function bar()
  --...
  return foo(a)
end

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.)

Rici