At 09:42 PM 9/3/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > 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.
>
>Sure, if you use eval, the symbol table for the current scope
>needs to be available. There's no reason to have more than
>one though -- all instances of an activation record share
>the same symbol table.
Well, we don't really keep around a single symbol table. We walk up the
pads until we find things that resolve, or so it looked the last time I
dove into the code.
>For the common case when we aren't debugging and a sub doesn't
>use string eval, it would be nice to use less memory and drop
>the scope's symbol table.
Sure, except for the whole "MY into the caller's package" thing. Or
scopeless subs, though I don't know if they've been talked about yet.
>Is %MY (with attributes presumably) really going to be the API
>to the symbol table?
Yes.
>Why don't we just have *one* API to the
>symbol table and use attributes to differentiate between dynamic
>and lexical scoping?
Beats me--ask a language guy. The two (global and lexical access) don't
feel the same, so I can't say I'd do them the same if I were designing it,
though.
> > 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.
>
>These things behave totally different in a closure though.
Ah. Closures. Forgot about those.
Yeah, they're trickier.
>A "temp" variable must have its' global binding restored when
>returning to the caller. But that leaves closures referencing
>the wrong variable.
>
>Anyways, since you say "oddly enough" and "silly thing", I suspect
>that you're aren't doing it this way. ;)
Definitely not. Global variable sets with runtime global local-equivalent
overrides are a lame hack, and we won't go there. Doesn't mean it can't be
done, just that it shouldn't. ;-P
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
