compile-time globals

[Thomas Lauer <thomas.lauer@...>]

Over the weekend I experimented with an extension to the parser to
enable the declaration of globals at compile time, similar to what the
local keyword does for local variables.

However, I've run into a problem that I can find no simple, elegant
solution for: module() is a runtime feature and the compiler knows
nothing about it: a switch to another module via module() will not, in
itself, make the compiler aware that there's now a different environment
for globals in place.

One obvious solution would be to include a few lines in the compiler to
parse module calls and to arrange things in such a manner that the
parser knows which module and environment is currently active. However,
this is no good, because modules can be anonymous:

module(...)
-- module definitions

Such a module is receiving its name only at runtime. In other words,
there is no obvious way the parser can build a table with the globals
for such a module. If I skip the ability to initialise global variables,
declaring them amounts to not much  more than setting a compile time
flag. This won't generate any VM code, so I could perhaps invent
something like an anonymous table for that purpose. Given the
complexities of require() and module(), given the fact that modules can
be arbitrarily nested within modules, this approach looks rather brittle
to me.

I am beginning to suspect that a comprehensive compile time feature to
declare (and check for undeclared) global variables is simply not
feasible. In other words, such checks can *in principle* only be
performed at runtime.

Is that suspicion correct?

-- 
cheers  thomasl

web : http://thomaslauer.com/start