> 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.
Yes. We're agreed then. What I *thought* I had found was a way to delegate a portion
of that task downward and outward but I was wrong.
> 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.
And that's what I'm planning to do now. Fortunately I've only got two scopes at the
language level to deal with:
* a strictly lexical scope. BASIC's subs and functions; anything
not in a sub is in an implied main()
* a global scope. Anything declared with COMMON.
I got nailed trying to implement the second by being clever: push declarations
(.local) of things declared COMMON from the scope in which it's seen to an outer
encasing scope. Thus in BASIC/Perl:
# BASIC
COMMON a
sub foo ()
a=1
c=3
end sub
a=15
usedonce=0
call foo()
# Perlish equivalent
{
my $a;
sub foo {
my $c;
$a=1;
}
sub main {
my $usedonce;
$a=15;
$usedonce=0;
foo();
}
}
So when I see occurances of "a", I'd look them up in the COMMON list and if they were
there, I'd simply not do the PIR declaration in the inner scope, and let the outer
declaration take care of it for me. They'd share a register and everthing would work.
Except that they don't share a register, and this doesn't work. I'll probably hack in
pads this weekend instead.
> 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.
It was there long enough to make it into P6E. *shrug* I'd only began looking at it
last month or so.
Afterthought: there aren't a lot of examples with nested .subs either. I've found two
in t/syn and they're not terribly demonstrative of their usefulness. What's
implemented there could be done without the outer .sub. *shrug*
> 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 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.
> 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.
I'm used to the concept in Macro Assemblers where I can designate registers, memory
addresses, etc... by name and those names have a particular scope. Usually this is to
a file, or to some kind of compilation unit. Thus I can mix and match (cut and paste)
bits together and either have them use the globally defined names (for special
hardware registers, etc...) or the locally defined ones.
In my mind, when I saw: 1. .local, 2. automagical register spillage in IMCC, and 3.
nested compilation units I thought I'd found Assembler Manna.
Either way: once things are decided and cast into stone, the documentation needs to be
unambiguous!
