[perl #31862] [BUG] Can't push a PMC onto a FixedPMCArray

[Will Coleda]

# New Ticket Created by Will Coleda
# Please include the string: [perl #31862]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31862 >

Shouldn't this push just like PerlArray except with bounds checking?

oolong:~/research/parrot coke$ cat foo.imc
#!./parrot
.sub main
$P0 = new PerlArray
$P1 = new FixedPMCArray
$P1 = 10
$P2 = new PerlUndef
push $P0, $P2
push $P1, $P2
end
.end
oolong:~/research/parrot coke$ ./foo.imc
push_pmc() not implemented in class 'FixedPMCArray'\noolong:~/research/parrot coke$

[Leopold Toetsch]

Will Coleda <parrotbug...@parrotcode.org> wrote:

> Shouldn't this push just like PerlArray except with bounds checking?

Fixed means really fixed for that PMC. BTW you can't push onto an Array
PMC either. Just use a ResizablePMCArray.

leo

[William Coleda]

So, this divides anything that provides an array like interface into two camps - those that support the push opcode, and those that don't. This means that whenever you write code that needs to be PMC agnostic (for example, any of the list processing commands in Tcl - after all, the could be called by someone elses languages, and I don't know if their arrays are resizeable), you have to avoid using push when implementing the code. Or, handle the exception and the fallback to a non push method of doing it (which seems like even /more/ work.)

If nothing else, this should probably be documented in stronger language in ops/pmc.ops. (Similar additions should probably be added for the other list manipulation opcodes as well) Though I'd be curious if a patch would be accepted to make all the array pmcs in classes/* support this.

Index: pmc.ops
===================================================================
RCS file: /cvs/public/parrot/ops/pmc.ops,v
retrieving revision 1.27
diff -b -u -r1.27 pmc.ops
--- pmc.ops 3 Sep 2004 09:27:21 -0000 1.27
+++ pmc.ops 6 Oct 2004 12:33:21 -0000
@@ -338,6 +338,8 @@
=item B<push>(in PMC, in PMC)

Push $2 onto the end of the aggregate PMC $1, if that operation is defined.
+Note that this opcode is only defined for I<resizable> array PMCs, not
+I<fixed> size array PMCs.

=cut

[Leopold Toetsch]

William Coleda <wi...@coleda.com> wrote:

> So, this divides anything that provides an array like interface into
> two camps - those that support the push opcode, and those that don't.
> This means that whenever you write code that needs to be PMC agnostic
> (for example, any of the list processing commands in Tcl - after all,
> the could be called by someone elses languages, and I don't know if
> their arrays are resizeable), you have to avoid using push when
> implementing the code. Or, handle the exception and the fallback to a
> non push method of doing it (which seems like even /more/ work.)

Well basically yes. But the "PMC agnostic" part isn't quite true. You
can't push onto an Integer PMC, nor onto an Hash. And you can't push
aka .append onto a Python tuple.

The same problem arises for a lot of other vtable methods like
get_number, which is implemented for scalars only.

> If nothing else, this should probably be documented in stronger
> language in ops/pmc.ops.

As said, the implemented vtable method depend on the PMC. Looking into
the documentation of that PMC should give you a list of all vtables.

$ perldoc -F classes/fixedpmcarray.pmc

leo

[Will Coleda]

On Wed, Oct 06, 2004 at 03:43:35PM +0200, Leopold Toetsch wrote:
> William Coleda <wi...@coleda.com> wrote:
>
> > So, this divides anything that provides an array like interface into
> > two camps - those that support the push opcode, and those that don't.
> > This means that whenever you write code that needs to be PMC agnostic
> > (for example, any of the list processing commands in Tcl - after all,
> > the could be called by someone elses languages, and I don't know if
> > their arrays are resizeable), you have to avoid using push when
> > implementing the code. Or, handle the exception and the fallback to a
> > non push method of doing it (which seems like even /more/ work.)
>
> Well basically yes. But the "PMC agnostic" part isn't quite true. You
> can't push onto an Integer PMC, nor onto an Hash. And you can't push
> aka .append onto a Python tuple.

I meant "Array PMC agnostic", of course. Dan pointed out that the Fixed
PMCs are not Bounded PMCs (which for some reason I thought they were), so
I'll settle for grousing to myself. =-)

> The same problem arises for a lot of other vtable methods like
> get_number, which is implemented for scalars only.
>
> > If nothing else, this should probably be documented in stronger
> > language in ops/pmc.ops.
>
> As said, the implemented vtable method depend on the PMC. Looking into
> the documentation of that PMC should give you a list of all vtables.
>
> $ perldoc -F classes/fixedpmcarray.pmc

The documentation should end up in docs/pmc after a build. Currently only a
small subset of documentation is generated.