So we finally get the hook operator as debated on p5p a long while ago. Thank you Larry :-)

Blessed Be
The Pixel

Perl might try to correct the parsing of:

$x = $y //foo/;
[download]

from

$x = $y // foo/;
[download]

to

$x = $y / /foo/;
[download]

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

Perl might try to correct the parsing of:

$x = $y //foo/;

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

/// or // should be more like s/// or m//

but what is $foo // or $brr /// (nothing if i remember correctly)

 $foo // expr has nothing to do with regex

oh "divide" by a regex, mmmkay, maybe something like

$_ = "2k4";
print ( 49 / /\d/); #?
[download]

(i can't see how what you're suggesting can occur, or i'm misunderstanding)

Can you give one example where dividing by a regexp is not hopelessly obfuscatory? If I saw someone trying to do that in production code, I would hesitate between shooting them first and then throwing them out the window, or doing it the other way around :)

Although I would be slightly more worried about the ambiguity between // "that unless defined this" and // "rematch according to the last successfully compiled regexp" (although maybe that's going away in Perl 6, I've lost track). And anyway, I'll let Larry and Damian worry about that for the time being.

--

g r i n d e r