Front page | perl.perl6.internals |
Postings from September 2001
Brent Dax wrote: > Ken Fox: > # Lexicals are fundamentally different from Perl's package (dynamically > # scoped) variables. > > *How* are they "fundamentally different"? Perl's "local" variables are dynamically scoped. This means that they are *globally visible* -- you never know where the actual variable you're using came from. If you set a "local" variable, all the subroutines you call see *your* definition. Perl's "my" variables are lexically scoped. This means that they are *not* globally visible. Lexicals can only be seen in the scope they are introduced and they do not get used by subroutines you call. This is safer and a bit easier to use because you can tell what code does just by reading it. > But in this case the pad is actually a full symbol table. The > concept is the same, the data structure is different. The concept isn't the same. "local" variables are globals. You only have *one* of them no matter how many times you call a sub. For example, threading or recursion might cause the same sub to have several copies "running" at the same time. With global variables (aka "local" variables) all the copies share the same global variables. With "my" variables each copy of the sub gets a brand new set of variables. This is known as an activation record. THIS IS COMPLETELY UNRELATED TO A SYMBOL TABLE! In both cases you have one symbol table. However, in the case of "my" variables you have *many* values for each variable. The particular value being used depends upon which activation record is being used. > There *is* run-time lookup in some contexts, such as a string eval. String eval isn't a run-time lookup. The code is *compiled* and then run. Also notice that string eval can't change the current lexical scope. It can create a new inner scope, but it can't introduce variables into the outer scope. Basically anything that "breaks" scoping barriers goes against the grain of lexical scoping. If an inner scope can modify its' parent, you've just destroyed one of the major advantages of lexical scoping. We tolerate symbol table globs with "local" variables because we've already admitted there's no hope of understanding what something does just by reading the code. We haven't corrupted "my" yet -- and I don't want to start! > In the end, all I'm doing is suggesting an alternate implementation > which should reduce our workload and make many concepts which currently > don't work with lexicals work correctly. Your proposal to use "temp" with flags to implement "my" doesn't even work, let alone achieve either of your goals. - KenThread Previous | Thread Next