I am not the best one to answer these questions, but I will make some comments anyway, though Dan is/was planning to give us an authoritative position doc on some of these issues.
I have done some work on some of this, but my latest code submission has not been accepted yet. On 9 Sep 2002, Juergen Boemmels wrote: > I have several questions regarding lexicals. > > There is a discrepancy between parrot_assembly.pod and core.ops > parrot_assembly.pod says that find_lex will return a pointer, where as > core.ops uses find_lex to retrive a value and store_lex to set this > value. Which of this is correct? > I would think it will become pointers. > parrot_assembly mentions a fetch_lex_p_i_i but there is no > implementation yet. This functions would be very handy when you know > at compile time whats in the lexical scope. Is this left-out > intentional or just because nobody has yet implemented it. In the > later case, is somebody already working on this? > This is still the plan and I believe that "by index" is going to be the fastest way to access lexicals. I have been thinking about implementing something for this but I am waiting to see if my previous patch gets committed so I can be sure I am heading in a reasonable direction. On the other hand maybe I should just press forward? > How are the integers of the lexicals in the pad assigned? I assume > they get increasing numbers for each store_lex, starting at 0 for a > new pad. Correct? > > How do I store to a lexical by number? Shouldn't be there also a > store_lex_i_i_p (or set_lex to indicate that it is a change of an > already existing binding). Dan has hinted that there will be some way, in parrot assembly, to provide a static pad descriptor that could be used to put all lexicals in place when the pad is first created. > Is there a possibility to get a pointer to the current pad, to store > it in the closure? (Im not sure, maybe only the top-pad is needed). > There need also be a way to reinstate the saved lexical. I have submitted code that does this sort of thing for subroutines. -- Jonathan Sillito
