That will depend on how the Perl 6 parser works. If it pre-tokenizes (like Perl 5 does) then we shall almost certainly still have a "longest interpretation possible" tokenizing rule. So:

$x = $y //foo/;

will have to be interpreted as:

$x = $y // foo/;

But if (as I hope) we tokenize on-the-fly, then the parser will be able to backtrack this incorrect interpretation and re-parse it as:

$x = $y / /foo/;

instead.

Indeed, if that is the parsing strategy, the issue here would never even arise, since the higher precedence of / over // would see that interpretation considered first. (Of course, there would be backtracking when compiling:

$x = $y //foo;

in that case, since the higher precedence interpretation doesn't work.)

Personally, I think JIT tokenization will be the only feasible approach for Perl 6, given how mutable the language will be (e.g. user-defined operators).

And, almost as a happy by-product, that is likely to inject the maximum degree of DWIMity into the language.

Damian

Excellent. I would have only assumed JIT tokenization was the course to be taken, after reading Larry's third Apocolypse. I'm looking forward to seeing some of your applications of these new ideas in your exegesis.

By the way, what is the purpose of a my sub? Is it just a way to have a "lexically scoped" function? That is, is it a way around the current my $func = sub { ... }; $func->(...); approach?

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

By the way, what is the purpose of a my sub? Is it just a way to have a "lexically scoped" function?

Exactly.

Although that "just" is a little unfair. Lexically scoped subs are a very significant addition to the language.

For example, they allow user-defined operators to take effect only in a limited -- and compile-time determinable -- scope, thereby preventing widespread chaos and madness when some module you import decides to define a high-precedence ;# operator and accidentally eats all your close-commented end-of-statements. ;-)