On Monday 03 September 2001 08:09 pm, 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?!
Scoping is different. Not the variables themselves. (Or the storage of
those variables.)
> > 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.
Except that Perl 6 will have the ability to inject lexical variables in its
scope, and in any dynamic parent's scope. (It isn't clear whether that is
write-only access or not - which it probably should be for lexicals.)
That, invariably, forces at least some run-time lookup by name, since the
lexicals aren't there at compile time for the early resolution.
>
> > 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.
As above, a variable could very well be looked up in lexical storage by name
first, and then in the global stashes.
>
> That's a huge difference over emulating "my" with "temp" like
> what was originally proposed!
I thought the *original* proposal was simply to make MY:: an actual symbol
table, vice its current array-based pad, to reduce the number of different
table-lookups (whether compile- or run-time) that we'd have to code and
maintain. There's no reason you couldn't do that. Yes, it'd be a waste of
space. Yes, it'd be slower, unless there were a lot of lexicals being
introduced. But there's no other reason why it couldn't work.
Brent just went wayward when trying to further explain.
--
Bryan C. Warnock
[EMAIL PROTECTED]
