At 12:39 AM 11/9/2001 -0500, Ken Fox wrote:
>There are a number of decisions to make about lexicals
>and the current PDD is pretty slim. So, IMHO, the place
>to start is with the PDD. Anybody have any more thoughts
>on the interface? Dan? Is this stone tablet stuff yet?
Nope, not stone tablet at all. More a sketch than anything else, since I'm
not sure yet of all the things Larry's got in store.
How we're handling MY variables is the big iffy thing. I'm not sure at the
moment whether we're going to need some sort of wacky trampoline scheme or not.
>The big five questions on my list are:
>
>1. The find_lex/fetch_lex ops push a lot of work into the
> run-time when the compiler can figure out what frame a
> lexical appears in.
>
> Should there be an alternative, faster interface to
> lexicals that eliminates string lookups?
You'll be able to fetch things out of hashes by index number, and the
lexical fetcher will handle this. So you only need to figure out the index
number once (potentially at compile time) and then fetch by number after that.
>The symbolic
> interface is required to support %MY and debugging, so
> it stays regardless of whether other interfaces exist.
>
>2. Perl 5 doesn't support nested subs, but I haven't read
> anything about Perl 6 and I don't know if other
> targets for Parrot support them either.
>
> Do we want to support nested subs? Efficiently?
When you say nested subs, do you mean lexical subs? If so, then yes. (If
not, then probably anyway. :)
>3. We've adopted a register machine architecture to
> reduce push/pop stack traffic. Register save/load
> traffic is similar, but not nearly as bad.
>
> Do we want to further reduce memory moves by allowing
> ops to work directly on lexicals?
No, I don't think so--that's what the registers are for. Fetch out the PMC
pointer into a PMC register and just go from there. Any changes made via
the pointer will, of course, be reflected in the lexical, since we're
working on the real thing.
>4. There has been discussion about how useful non-PMC
> registers will be to the Perl compiler. If there are
> questions there, surely non-PMC lexicals would be even
> less useful to Perl.
>
> Do we want non-PMC lexical support?
Nope, I wasn't going to bother. All variables are PMCs. The int/string/num
things are for internal speed hacks.
>5. Perl 5 uses pads and scratchpads for holding lexicals.
>
> Do we want to consider other implementations such as
> traditional stack frames with a display or static
> link?
Well, I don't think we can go with traditional stack frames as such, since
the individual frames (and their children) may need to stick around for
ages, courtesy of closures and suchlike things. (We almost end up with a
linked list of stacks when you factor recursion in)
How it gets handled depends to some extent on the requirements that Larry
puts on lexicals.
>If there aren't any obvious answers, I propose that we
>implement a couple different approaches and objectively
>compare them.
Works for me.
>Lexical implementation is as critical to
>Perl's performance as the dispatcher is, so we should
>take some time to get it right.
I'm not sure it's as performance critical, but it's definitely important.
Fast is, of course, good. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
