At 08:09 PM 9/3/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 05:44 PM 9/3/2001 -0400, Ken Fox wrote:
> > > Lexicals are fundamentally different from Perl's package (dynamically
> > > scoped) variables.
> >
> > No, actually, they're not.
>
>How can you possibly think that lexical scoping and dynamic scoping
>are not fundamentally different?!
I don't. However, stashes and pads aren't (or don't have to be)
fundamentally different.
> > > Even if you could somehow hack package variables
> > > to implement lexicals, it would waste space duplicating a symbol table
> > > for each instance of a lexical scope.
>
> > The big difference between lexical variables and package variables is that
> > lexicals are looked up by stash offset and package variables are looked up
> > by name.
>
>Right. So how is a hash table smaller than an array?
It's not. They're bigger, pretty much by definition. So?
> > The real question, as I see it, is "Should we look lexicals up by name?"
> > And the answer is Yes. Larry's decreed it, and it makes sense. (I'm
> > half-tempted to hack up something to let it be done in perl 5--wouldn't
> > take much work)
>
>Where is the sense in this? Certainly the compiler will look things
>up by name, but the run-time doesn't need to.
The runtime does have to. For several reasons.
First, of course, runtime and compiletime are mixed on perl. String eval
has to go walk back up the pads *at runtime* and resolve the variable names.
Second, Larry's decreed you'll be able to look up lexicals by name using
the MY hash. And look up at outer levels. How do you plan to look up
variables by name when you're peering outside your compilation unit? With a
key that can be resolved only at runtime?
> > The less real question, "Should pads be hashes or arrays", can be answered
> > by "whichever is ultimately cheaper". My bet is we'll probably keep the
> > array structure with embedded names, and do a linear search for those rare
> > times you're actually looking by name.
>
>That doesn't sound like we're looking up by name at all... It
>sounds like the compiler is emiting frame pointer offsets, but
>there's a pointer to the symbol table stored in the frame just
>in case something wants to see the names.
It sounds like "Pads might be arrays with names embedded in the slots, or a
hash, whichever's more efficient". I'm not sure which would be, but I've a
good idea. :)
>That's a huge difference over emulating "my" with "temp" like
>what was originally proposed!
That, oddly enough, is doable with enough compiler work. A silly thing, but
doable. It's irrelevant to the question as it had evolved, namely "what's
the difference between a stash and a pad?" We could, after all, associate a
new stash with each level of lexical scope if we were so inclined. Or make
stashes and pads identical under the hood and just reference them differently.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
