On Fri, Mar 28, 2008 at 2:20 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Thu, Mar 27, 2008 at 10:33:54PM +0100, Klaas-Jan Stol wrote: > > On Wed, Mar 26, 2008 at 6:30 PM, Patrick R. Michaud <[EMAIL PROTECTED]> > wrote: > > > On Wed, Mar 26, 2008 at 02:25:06PM +0100, Klaas-Jan Stol wrote: > > > > > * list ops ( I think this is meant by list ops? ) > > > > All languages that have some kind of scope mechanism now have to > > > > define a class "List", which has an unshift and shift method, which > > > > are just wrappers for the equally named parrot ops. > > > > > > I don't quite understand what is meant by "have to define a class > > > 'List'". Can you give an example? > > > > Yes, sorry, I didn't explain the context. In order to write > > @?BLOCK.shift() (and unshift() ) (for implementation of the scope > > stack in pretty much all languages), @?BLOCK must be an object that > > has these methods. As ResizablePMCArray doesn't have such methods, the > > "trick" here is to subclass ResizablePMCArray (calling it "List") and > > wrapping the shift and unshift instructions in the equally-named > > methods. > > Actually, it can be done without subclassing via the following > > .namespace [ 'ResizablePMCArray' ] > > .sub 'unshift' :method > .param pmc list > .param pmc value > unshift list, value > .end > > .sub 'shift' :method > .param pmc list > .param pmc value > shift list, value > .end > > > I've already commented that perhaps these should be a built-in > part of the ResizablePMCArray in Parrot. However, if that's > not likely to happen, then perhaps either PCT or NQP should > go ahead and provide them, so that they're available whenever > PCT is loaded. But part of me feels that adding methods to > ResizablePMCArray is a little out of NQP's scope. > > So, our choices become: > > 1. Have NQP automatically recognize shift/unshift/push/pop > as "special functions" (keywords) and map them directly to > Parrot's shift/unshift opcodes. > > 2. Add shift/unshift/push/pop methods to ResizablePMCArray > (or one of its superclasses) in Parrot > > 3. Have PCT and/or NQP supply the shift/unshift/push/pop methods. > > 4. Have PCT and/or NQP define their own "List" subclass > that provide shift/unshift/push/pop (this could conflict with > "List" classes in other languages). > > 5. Advise compiler writers to use some other existing class > for things like @?BLOCK (any of Capture_PIR, Match, or PAST::Node > would work, but could be confusing). > > Opinions from the gallery would be greatly welcomed here. > > The other items in your message all make good sense and > I think I'm likely to adopt them as soon as we can get > implementations for them. :-)
Attached is a patch implementing: * ++ and -- postfix operators, implemented as n_sub and n_add (taking "1" as the 3rd operand), this is because each instruction must have an output register as far as I can tell (so "inc"/"dec" won't work). I wasn't sure how to implement +=; how to spell that? (as there's only a ":=" operator right now). I figured that ++ and -- are probably more used anyway, and if you want to += 2, then you can always use the normal assignment syntax. * <, <=, > and >= operators kjs > > Thanks! > > Pm >
nqp_proposals.patch
Description: Binary data
