[cc'd to perl6-internals] "Jonathan Sillito" <[EMAIL PROTECTED]> writes:
[...] > If I remember correctly Sean's patch did store the scratchpad with the > Sub.pmc, except that I retreived it from the current context's pad_stack. > Then when Sub.pmc was invoked it pushed the correct pad on the stack. I > notice that you are using P31 instead of the pad_stack. I probably missed > the discussion about this, but was the pad_stack approach not working? If > you have the time would you mind explaining to me what in particular was not > working? The current pad_stack handling is very much tied to Sub.pmc. The only way of getting the current scope is creation of a new sub; the only way setting the current pad is invoking this sub. But I didn't used Sub.pmc, partly because the lexical scope is not working in CVS subs and i don't want to add yet another set of prepatches, partly because I added the formal parameters to the procedure object. So I think there are two possible ways out: adding operations to core.ops (get_current_pad_p and new_pad_p) or rolling the lexical pad on my own. And there is a diffrence between define and set!, define creates a new binding in the top lexical scope, ignoring every previous definition, but set! changes the binding of a formerly defined variable. This 2 diffrent operations don't map very well on the store_lex_s_p operation. I used the diffrent keyed access methods of Seans Scratchpad.pmc for differentating this use cases: define : P31[-1;S0] set! : P31[S0] bye boe -- Juergen Boemmels [EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
