PMC elements() inaccessible from the assembler?

[Stéphane Payrard]

When I grep core.ops, I don't see any mention of elements()
but vtable.tbl and actual PMC have elements().
How can I access the PMC method elements from the assembler?

The closest opcode is set(out INT, in PMC) which calls
$2 get_integer().

To augment the confusion ./docs/overview.pod speaks of
a fictitious length() method:

"
(pmc->vtable->length)(pmc);

If our PMC is a string and has a vtable which implements Perl-like
string operations, this will return the length of the string. If, on the
other hand, the PMC is an array, we might get back the number of
elements in the array. (If that's what we want it to do.)

"

I believe that 'length' should be replaced by 'elements' in that pod.

If I trust pdd02_vtables.pod, I believe that get_integer() and
elements() are different PMC methods.

BTW I don't remember how one is suppose to call get_integer() and
elements() from Perl6:

$a = @a.length ; # should this translate in elements()?
$a = @a # should the Perl6 that translate into get_integer().

I understand that for arrays get_integer() currently calls elements()
but this is beside my point.

--
stef

[Leopold Toetsch]

Stéphane Payrard wrote:

> When I grep core.ops, I don't see any mention of elements()
> but vtable.tbl and actual PMC have elements().

Yep that's correct. If you continue grepping in core.ops/vtable you'll
find a lot more inconsistencies, mainly:
- almost all of the _keyed ops
- many string functions

This all needs major cleanup, when its finally clear what vtable methods
will remain and how core.ops is changed accordingly.

leo

[Benjamin Goldberg]

Stéphane Payrard wrote:
[snip]

> BTW I don't remember how one is suppose to call get_integer() and
> elements() from Perl6:
>
> $a = @a.length # should this translate in elements()?
> $a = @a # should the Perl6 that translate into get_integer().
>
> I understand that for arrays get_integer() currently calls elements()
> but this is beside my point.

IIRC, doing $a = @a in perl6 is like doig $a = \@a in perl5 -- it merely
gets a reference to the array.

No comment on whether @a.length should call be compiled to a call to
get_integer() or elements().

--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

[Luke Palmer]

> Stéphane Payrard wrote:
> [snip]
> > BTW I don't remember how one is suppose to call get_integer() and
> > elements() from Perl6:
> >
> > $a = @a.length # should this translate in elements()?
> > $a = @a # should the Perl6 that translate into get_integer().
> >
> > I understand that for arrays get_integer() currently calls elements()
> > but this is beside my point.
>
> IIRC, doing $a = @a in perl6 is like doig $a = \@a in perl5 -- it merely
> gets a reference to the array.
>
> No comment on whether @a.length should call be compiled to a call to
> get_integer() or elements().

Depending on the type of $a. For regular untyped scalars, yes, that
is the case.

If you're worrying about the behavior in the ops, don't. P6 will,
most likely, explicitly ask for what it needs in all of these such
cases.

Luke