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«3␤Method '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«===SORRY!===␤Undeclared
> routine:␤ 'x' used at line 2␤Check failed␤FAILED 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

Reply via email to