At 7:43 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 7:32 PM, Dan Sugalski wrote:

At 7:28 PM -0700 9/24/04, Jeff Clites wrote:
On Sep 24, 2004, at 6:51 PM, Aaron Sherman wrote:

However, the point is still sound, and that WILL work in P6, as I
understand it.

Hmm, that's too bad--it could be quite an opportunity for optimization, if you could use-and-discard lexical information at compile-time, when you know there's no eval around to need it.

Even if not it's going in anyway. The introspection abilities are more than worth the extra memory that the name hashes use.

It's a compiler issue.

Well... sorta. It's a specification issue.

*Not* having pads of some sort, whether they're dull, bog-simple activation frames which're just arrays, or the more complex ordered hash system we've gone with, makes continuations untenable. You need a stable backing store, otherwise resuming a continuation's a dodgy thing. (Though that's usually not too big a deal, as you've normally saved registers at any spot where a continuation could be taken, so the risks are minimized) It also makes up-call lexical peeking and modification impossible. This is something Larry's specified Perl 6 code will be able to do.

That is, any routine should be able to inspect the environment of its caller, and modify that environment, regardless of where the caller came from. That means that you can't really optimize it away at compile time, since you can't know at compiletime what your call path is going to look like. (To a point. Leaf subs and methods can know, if we stipulate that vtable methods are on their own, which is OK with me)

(And I'm less worried about the memory than I am about all of the pushing and popping and by-name stores and lookups, which could optimized away to just register usage.)

There shouldn't be much, if any, pushing and popping for stuff like this, and access to lexical pads should be an O(1) operation. Remember, you know at compile time what lexical variables are in scope which means if you have a data structure which can be accessed by name and index (like, say, the OrderedHash PMC clas...) most, if not all, of the access to lexicals will be by integer index. That access is also likely to be a one-time deal -- since PMCs are all dealt with by pointer you only need to fetch the pointer out of the store (or put it in for a new PMC) once. It's unlikely that any sub or method's going to find its runtime dominated by the time it takes to store PMC pointers into an array... :)
--
Dan


--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to