On Sat, Oct 04, 2008 at 05:09:47PM -0400, Bob Rogers wrote:
Content-Description: message body text
>    From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>    Date: Sat, 4 Oct 2008 09:41:22 -0500
> 
>    On Fri, Oct 03, 2008 at 09:47:38PM -0700, Larry Wall wrote:
>    > On Fri, Oct 03, 2008 at 11:57:30PM -0400, Michael G Schwern wrote:
>    > : What's the status of numeric upgrades in Perl 6?  Is see the 
>    > : docs say "Perl 6 intrinsically supports big integers and rationals 
>    > : through its system of type declarations. Int automatically 
>    > : supports promotion to arbitrary precision" but it looks like it's 
>    > : doing the same thing as Perl 5.
>    > 
>    > The status of numeric upgrades in Perl 6 is fine.  It's rakudo that
>    > doesn't do so well.  :)
> 
>    Correct.  I suspect that eventually the Rakudo developers will have
>    to develop a custom set of PMCs for Perl 6 behaviors rather than
>    relying on the Parrot ones.
> 
> The Parrot behavior in this case may be closer than you think.  After
> applying the patch below, I get the expected output from Rakudo:
> 
>       [EMAIL PROTECTED]> ./perl6 -e 'say 2**40'
>       1099511627776
>       [EMAIL PROTECTED]> ./perl6 -e 'say 2**50'
>       1125899906842624
> [...]
> 
> It does produces >300 spectest_regression failures, though, so I don't
> claim the patch is right.

One of the big problems with Parrot's n_* opcodes is that they
often assume that the type of the result should be the same as
the type of the first operand.  So, given (Perl 6) code like

    my @a = <abc def>;
    say @a * 2147483648;

the PIR translation using n_mul fails because it doesn't
know how to n_mul a ResizablePMCArray:

    $ cat v.pir
    .sub main
        ##  Perl 6:  my @a = <abc def>;
        .local pmc a
        a = new 'ResizablePMCArray'
        a[0] = 'abc'
        a[1] = 'def'
    
        ##  Perl 6:  say @a * 2147483648
        $P1 = n_mul a, 2147483648
        say $P1
    .end
    $ ./parrot v.pir
    MMD function __multiply not found for types (58, -99)
    current instr.: 'main' pc 11 (v.pir:9)
    $

All of the mechanisms I've been able to find in Parrot for 
converting an arbitrary PMC to a number seem to result in 
the code for infix:<*> that we have now.  I'm open for 
suggestions to improve this, though.

Pm

Reply via email to