On Wed Nov 12 08:07:43 2008, pmichaud wrote:
> On Tue, Nov 11, 2008 at 08:43:09AM -0800, Carl Mäsak wrote:
> > <masak> rakudo: for "foo\nbar\nbaz".split( /\n ** 2..*/ ) { say
> > .trans([ /\s+/ => " " ]) }
> > <p6eval> rakudo 32543: OUTPUT[too few arguments passed (2) - 3 params
> > expectedcurrent instr.: '_block25' pc -342568903 ((unknown
> > file):-1)]
> > <masak> HAH!
> > * masak files ticket
>
> The problem is that the strings returned in PGE's Match objects
> are Parrot String PMCs, and so the .trans method for String PMCs
> (src/pmc/string.pmc:867) ends up being used instead of the .trans
> method defined by Rakudo.
>
> This will all likely be fixed when we have HLL mapping in place,
> and when PGE is updated to understand HLL mapping. Until then, I
> think we're a little stuck on this one.
As a start towards fixing this, I've added a String.Scalar method that
will promote Parrot String PMCs into Rakudo Str objects whenever the
String PMC is asked for its scalar value (e.g., upon assignment).
So, while $/[0].trans(...) will still go to the wrong object, assigning
$/[0] to a scalar and then performing .trans(...) will get closer to
what you want.
Again, a lot of this gets solved by HLL mapping -- but even once we have
HLL mapping this can be a very useful backstop.
We also now have the .PARROT method, which can be used to find out
exactly what type of object Parrot thinks something is (as opposed to
how Rakudo sees it).
Pm
