From @masak

<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«�[31m===�[0mSORRY!�[31m===�[0m␤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)

@coke - Status changed from 'new' to 'open'

From @coke

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«�[31m===�[0mSORRY!�[31m===�[0m␤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

From @timo

Put a test case next to very similar test cases in
S02-names/identifier.t in f0fb59d.

@timo - Status changed from 'open' to 'resolved'