> If you want true variables around compilations units, please use globals > or lexicals if they are in the same lexical pad. > > [1] This "feature" is IMHO at the boarders of imcc as the namespace > instructions is. Should the HL handle these or imcc? But if its as > confusing as your test case, I would say I'll rather not support this > inside imcc.
My vote? Rip it out completely. It's *terribly* confusing. (And sends me back to the drawing board, at a cost of speed.)
Clint, I'm not sure which feature you mean is confusing here. I think you are referring to supporting .local outside of subs, and I agree with that. However, I think symbol tracking and scope checking is the high level language's responsibility so the example you provided really should not be so big of a deal, we should just put back the correct semantic checks for symbols.
Then if a language like Perl wants a funky scope type such as "local" (not to be confused with IMCC .local) then it can implement them at a higher level.
I've not been paying attention lately, but your example was the first I'd seen using
.local outside a sub, and I don't recall writing the grammar to support
that, so I assume this was a feature Leo patched in lately.
Either option works for me:
1) We can define semantics for .local at the module (file) level, and at
the sub level, and correct the compiler so your example works2) We generate a parse error and disallow it, but at least don't accept it as valid code.
I trust Leo will make whichever choice for good reason, but my vote is in for (2) because it keeps IMCC simpler.
-Melvin
PS: I also don't care for nested sub definitions at an intermediate language level. They aren't real closures, so I don't see the point. Let the HL compiler implement them.
