On Sun Jun 13 10:07:20 2010, masak wrote: > <pmichaud> okay, someone review what I'm doing and please tell me I'm > missing something obvious... http://paste.lisp.org/+2DYG > > pmichaud@orange:~/rakudo$ cat x > > our sub xyz($abc) { say $abc.WHAT; } > > xyz(1); > > pmichaud@orange:~/rakudo$ ./perl6 x > ===SORRY!=== > Confused at line 2, near "our sub xy" > pmichaud@orange:~/rakudo$ > > <pmichaud> oh, I found a bug for masak! > <masak> pmichaud: that one should definitely not error out. > <pmichaud> if I change the name of the sub to something else it works. > <pmichaud> apparently it doesn't like 'xyz' > <moritz_> is there a quote form beginning with x? > <moritz_> rakudo: Quox > <p6eval> rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near > "Quox"» > <moritz_> same error > <masak> rakudo: our sub xyz($abc) { say $abc.WHAT; }; xyz(1); say > "alive" > <p6eval> rakudo ecacff: OUTPUT«Int()alive» > <masak> pmichaud: it only manifests in a file? > <pmichaud> it's also fine if there's a semicolon after the block > <masak> oh. > <pmichaud> I'm guessing it's being confused by operator x > <masak> rakudo: our sub xyz($abc) { say $abc.WHAT; } xyz(1); say > "alive" > <p6eval> rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near > "our sub xy"» > * masak submits rakudobug > <pmichaud> it's parsing as &infix:<x> > <pmichaud> what does STD.pm have to say about it, I wonder? > <moritz_> rakudo: our sub xyz($x) { say $x }xyz 3 > <p6eval> rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near > "our sub xy"» > <moritz_> std: our sub xyz($x) { say $x }xyz 3 > <p6eval> std 31238: OUTPUT«ok 00:01 109m» > <pmichaud> rakudo: our sub xyz($x) { say $x }xyz 3 > <p6eval> rakudo ecacff: OUTPUT«===SORRY!===Confused at line 11, near > "our sub xy"» > <pmichaud> rakudo: our sub xyz($x) { say $x }+ xyz 3 > <p6eval> rakudo ecacff: OUTPUT«3Method 'Num' not found for invocant > of class 'Perl6Sub' [...] > <masak> pmichaud: what's that last evaluation? > <masak> pmichaud: where does Perl6Sub enter into it? > <pmichaud> masak: the + is acting like an infix:<+> > <pmichaud> where it ought to be a prefix:<+> > <masak> due to the same whitespace bug? > <pmichaud> yes > <pmichaud> I'm going to need to run STD on it to see how STD handles > it > <masak> so this all goes into the same ticket? > <pmichaud> it's the same problem, just demonstrating that the problem > is not strictly a ltm issue > <pmichaud> anyway, I want to make sure that STD doesn't see that 'x' > as &infix:<x> > <pmichaud> (and then I'll figure out _how_ STD does it :) > <diakopter> std: sub xyz ($abc) { say $abc.WHAT }x 3 > <p6eval> std 31238: OUTPUT«[31m===[0mSORRY![31m===[0mUndeclared > routine: 'x' used at line 2Check failedFAILED 00:01 106m» > <pmichaud> right > <pmichaud> so there's something missing in rakudo's close-brace > handling logic again > <pmichaud> anyway, I'll figure it out later. > <moritz_> shouldn't it see it as statement-ending because the next > thing is a newline? > <pmichaud> sure, but the expression parser keeps going anyway > <pmichaud> actually, I misstated that > <pmichaud> the close brace is indeed marking end of statement > <pmichaud> but the expression parser is ignoring the end-of-statement > condition > <pmichaud> the expression parser thinks "aha, whitespace and an infix, > I know what to do!" > <pmichaud> (because we're in the expression parser at the time this > gets parsed)
Rakudo seems to be fine with this now: 21:01 < [Coke]> rakudo: our sub xyz($abc) { say $abc.WHAT; } xyz(1); say "alive" 21:01 <+p6eval> rakudo 38907e: OUTPUT«Int()alive» 21:01 < [Coke]> rakudo: our sub xyz($x) { say $x }xyz 3 21:01 <+p6eval> rakudo 38907e: OUTPUT«3» $ cat foo our sub xyz($abc) { say $abc.WHAT; } xyz(1); $ ./perl6 foo Int() Closable with tests. -- Will "Coke" Coleda