> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > 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. >
It would be nice if parrot provided the lexical scope semantics scheme (and other languages) needs rather than have each language implement their own. I guess this would be Dan's call, but just as another suggestion, could the lexical ops be limited to something like the following, plus keyed access to the pad? new Px, .ScratchPad push_pad Px peek_pad Px pop_pad Px (The find_lex and store_lex ops would be unnecessary, but could be kept of course) > 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] > Assuming Sean's patch (not my above suggestioned ops), would this implement the correct semantics for scheme's (define a ...): new_pad 1 new P0, .SchemeUndef store_lex 1, "a", P0 # ... pop_pad and could (set! a 12) inside of the above define be: new P0, .SchemeInteger store_lex "a", P0 # looks back through nested pads -- Jonathan Sillito
