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. :-)
Thanks!
Pm
