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'm not too sure, but it seems, that all named variable handling of an interpreted HL finally ends up in either find_global/store_global or lexical pad opcodes. The latter may be optimized to just a parrot register access, if no introspective features or eval are present.
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.
Yes, I did put it in on popular demand, and - yes - its already the second time that this leads to confusion. The current behavior is clearly a bug.
1) We can define semantics for .local at the module (file) level, and at the sub level, and correct the compiler so your example works
2) 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.
If language writers can agree on a more highlevel like variable handling WRT globals/named locals, I'd emit just corresponding parrot opcodes including scope frames (which we don't have yet). If $HL differ already too much at this level, I'm for 2) too.
-MelvinYes, they are useful only, if the whole variable stuff is done too.
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.
leo
