[perl #41825] morph vtable method not working in PIR

[Richard @ Hive-Systems . Com]

# New Ticket Created by ***@hive-systems.com
# Please include the string: [perl #41825]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41825 >


Hi,

Given the following:

.namespace ['A']

.sub 'morph' :method :vtable
say 'morphing!'
.end

.sub main :main
$P0 = newclass 'A'
$P1 = new 'A'
morph $P1, .Undef
.end

the 'morph' vtable method doesn't get called

Cheers,
Rich

[Christoph Otto via RT]

Post by Richard @ Hive-Systems . Com
Hi,
.namespace ['A']
.sub 'morph' :method :vtable
say 'morphing!'
.end
.sub main :main
$P0 = newclass 'A'
$P1 = new 'A'
morph $P1, .Undef
.end
the 'morph' vtable method doesn't get called

Works for me in 0.5.0 (r22925), if I remove :method from the 'morph'
declaration. Can you confirm?

I'm still seeing the broken behavior in r30915.

[Kjstol]

On Thu, Jan 15, 2009 at 6:32 PM, Andrew Whitworth via RT <

Okay, I've committed a variant of my patch in r35599, but I've run into
some issues while trying to test this. The morph VTABLE interface takes
an INTVAL which represents the PMC type to morph to. This is the value
that's passed to the morph subroutine. However, there's no easy way
(that I know of) to work with these numbers from PIR. For instance, you
can't create a new PMC of that type from the number, you can't convert
that number to the stringified name of the PMC, you can find out what
the type number is of an existing class, etc.
1) Add some opcodes such as "typename_s_i" and "typenumber_i_s" that
would convert between the string name of the PMC and the given type
number or

aren't those the type ids that we're trying to get rid of? :-)
I think option 2, using strings to specify the type, is better. (should
simple, single strings be enough, or do we want namespaces etc. here as
well? Somehow it seems to me this is related to the recent discussion about
class names, namespaces and HLLs.)

kjs

2) Change src/pmc/object.pmc:morph() to pass the stringified name to the
PIR override instead of the INTVAL type number.
I like the second one the best since type numbers may change internally
and we don't want people to be relying on them for other purposes.
However, then the morph vtable override in PIR will take a different
parameter list from the C version of the VTABLE interface, which might
get confusing.
Any suggestions?
--
Andrew Whitworth
a.k.a Whiteknight
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Will Coleda]

On Thu, Jan 15, 2009 at 1:32 PM, Andrew Whitworth via RT

Okay, I've committed a variant of my patch in r35599, but I've run into
some issues while trying to test this. The morph VTABLE interface takes
an INTVAL which represents the PMC type to morph to. This is the value
that's passed to the morph subroutine. However, there's no easy way
(that I know of) to work with these numbers from PIR. For instance, you
can't create a new PMC of that type from the number, you can't convert
that number to the stringified name of the PMC, you can find out what
the type number is of an existing class, etc.

As kj pointed out, this interface was deliberately removed from PIR.

1) Add some opcodes such as "typename_s_i" and "typenumber_i_s" that
would convert between the string name of the PMC and the given type
number or

-1

2) Change src/pmc/object.pmc:morph() to pass the stringified name to the
PIR override instead of the INTVAL type number.

More generally, change the morph vtable to take a 'Type' instead of an
it. In fact, given recent discussions about types on other threads,
this should probably take a PMC, not a String, and take the same types
as 'new' does.

Then we remove one more point where the int number was exposed
outstide of the C api.

I like the second one the best since type numbers may change internally
and we don't want people to be relying on them for other purposes.
However, then the morph vtable override in PIR will take a different
parameter list from the C version of the VTABLE interface, which might
get confusing.
Any suggestions?
--
Andrew Whitworth
a.k.a Whiteknight
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Patrick R. Michaud]

Not a string, a PMC (like Coke said). String type names are almost as
bad as type IDs. And check the performance on the branch, as I'm not
sure how heavily PGE is using morph. We may need both integer and PMC
versions of morph for the internals, but only allow the PMC one to be
overridden from PIR.

Just for the record, AFAICT none of PGE/PCT/Rakudo make use of
morph any longer. We now have the 'copy' opcode to do what the
"morph workaround" was doing (and I don't think copy is using
VTABLE_morph).

Pm

[Jonathan Worthington]

Post by Patrick R. Michaud
Just for the record, AFAICT none of PGE/PCT/Rakudo make use of
morph any longer.

This is true AFAIK too.

Post by Patrick R. Michaud
We now have the 'copy' opcode to do what the "morph workaround" was doing (and I don't think copy is using VTABLE_morph).

IIRC, copy once used to, but stopped doing so when I realized that we
morphed...and then copied right over whatever morph might have produced. :-)

FWIW, I've yet to find a use case for morph in anything I've done in
Rakudo. Between the copy op and our rebless_subclass dynop, we've got
what we've needed to date.

I'm curious - is anyone else doing a HLL on Parrot that uses morph? If
nobody is, is it worth spending time on, or even worth keeping?

Thanks,

Jonathan

[Will Coleda]

On Sat, Jan 17, 2009 at 11:11 AM, Jonathan Worthington

Post by Jonathan Worthington

Post by Patrick R. Michaud
Just for the record, AFAICT none of PGE/PCT/Rakudo make use of
morph any longer.

This is true AFAIK too.

Post by Patrick R. Michaud
We now have the 'copy' opcode to do what the "morph workaround" was doing (and I don't think copy is using VTABLE_morph).

IIRC, copy once used to, but stopped doing so when I realized that we
morphed...and then copied right over whatever morph might have produced. :-)
FWIW, I've yet to find a use case for morph in anything I've done in
Rakudo. Between the copy op and our rebless_subclass dynop, we've got
what we've needed to date.
I'm curious - is anyone else doing a HLL on Parrot that uses morph? If
nobody is, is it worth spending time on, or even worth keeping?
Thanks,
Jonathan

Tcl is using it, but only because we copied it from the Perl5 sample
stuff a very long time ago. If it goes away, we can probably live with
copy.

[Andrew Whitworth]

Post by Will Coleda
On Sat, Jan 17, 2009 at 11:11 AM, Jonathan Worthington

Post by Jonathan Worthington
I'm curious - is anyone else doing a HLL on Parrot that uses morph? If
nobody is, is it worth spending time on, or even worth keeping?
Thanks,
Jonathan

Even if the morph opcode isn't used often, the morph VTABLE interface
is used quite a bit internally. There really isn't any easier and
still standard way of changing between types for PMCs. It certainly
beats having to invoke PMC methods internally to switch between types.

--Andrew Whitworth

[Chromatic]

Post by Andrew Whitworth
Even if the morph opcode isn't used often, the morph VTABLE interface
is used quite a bit internally. There really isn't any easier and
still standard way of changing between types for PMCs. It certainly
beats having to invoke PMC methods internally to switch between types.

I haven't been awake long, but could internal code call whatever the copy
opcode calls?

-- c

[Andrew Whitworth]

Post by Chromatic
I haven't been awake long, but could internal code call whatever the copy
opcode calls?

I guess I don't know what people are talking about here with copy.
But, I would be hesitant to remove morph in order to rely on some
sideeffect of a different operation. If we want PMCs to be able to
change their types, we want to use something that's specific for that
behavior, not a copy that happens to be able to change the type of the
things it copies.

--Andrew Whitworth

[Bob Rogers]

From: Jonathan Worthington <***@jnthn.net>
Date: Sat, 17 Jan 2009 17:11:23 +0100

I'm curious - is anyone else doing a HLL on Parrot that uses morph?

Not me.

-- Bob Rogers
http://www.rgrjr.com/