[RFC] unary operations

1 view
Skip to first unread message

Leopold Toetsch

unread,
Apr 22, 2005, 11:51:19 AM4/22/05
to Perl 6 Internals
All infix operations are now converted to the new scheme. The most
visible part of the change is that infix operations now *can* return a
new destination PMC:

Px = n_add Py, Pz # create new Px as sum(Py, Pz)

and that overloaded infix functions have to return the result.

For Python, Lisp and probably more HLLs the same is of course needed for
unary opcodes:

abs Px, Py # use existing abs, Px exists
Px = n_abs Py # create new abs result PMC

This is of course just a fancy way to write

n_abs Px, Py # same

but it makes it more clear that a new value is assigned.

For the existing unary opcodes with PMC variants:

abs, neg, not, nots (don't we have more?)

the same scheme as to infix opcodes apply: if the passed in C<dest> PMC
is NULL, a new result PMC is created. I don't know, if we should have
distinct inplace variants too:

abs Px # VTABLE_i_absolute()

I'd like additionally to have PMC variants of mostly existing vtables
that currently return native types only:

PMC *get_str() # string context
PMC *get_num() # numeric context
PMC *get_int() # get integer (maybe)
PMC *get_list() # list context
PMC *hash() # get hash value - we have INTVAL hash()

The exsiting C<INTVAL get_bool()> should better be C<get_bool_native> so
that we have too:

PMC *get_bool()
PMC *get_bignum() # exists
PMC *get_complex() # return a new complex with SELF.value

I think these all should just return a new result PMC.

Comments welcome,
leo

Leopold Toetsch

unread,
Apr 28, 2005, 11:40:11 AM4/28/05
to perl6-i...@perl.org
Leopold Toetsch <l...@toetsch.at> wrote:

I've implemented this part now:

> For Python, Lisp and probably more HLLs the same is of course needed for
> unary opcodes:

> abs Px, Py # use existing abs, Px exists
> Px = n_abs Py # create new abs result PMC

> This is of course just a fancy way to write

> n_abs Px, Py # same

> but it makes it more clear that a new value is assigned.

> For the existing unary opcodes with PMC variants:

> abs, neg, not, nots (don't we have more?)

Actually the ops are:

abs, neg, not, bnot, bnots

and new:

n_abs, n_neg, n_not, n_bnot, n_bnots

> the same scheme as to infix opcodes apply: if the passed in C<dest> PMC
> is NULL, a new result PMC is created. I don't know, if we should have
> distinct inplace variants too:

> abs Px # VTABLE_i_absolute()

Done too plus a few missing unary inplace variants.

leo

Reply all
Reply to author
Forward
0 new messages