If you'd like to turn this into a doc-u-bug, that's fine; please open a ticket at
https://github.com/perl6/doc/issues On Mon, Jan 16, 2017 at 11:37 AM, Parrot Raiser <1parr...@gmail.com> wrote: > Any time there's a bug report based on a serious misunderstanding of > language behaviour by someone otherwise apparently competent, should > it be considered an LTA for the relevant part of the documentation? > > On 1/15/17, jn...@jnthn.net via RT <perl6-bugs-follo...@perl.org> wrote: >> On Sun, 15 Jan 2017 05:06:21 -0800, ronaldxs wrote: >>> So "42" ~~ / [ "0" || "42" ] | "4" / matches 4 but if you stick to just >>> one kind of alternation: >>> >>> "42" ~~ / [ "0" | "42" ] | "4" / >>> >>> "42" ~~ / [ "0" || "42" ] || "4" / >>> >>> the match correctly comes back with 42. It looks like in the mixed case >>> the "|" longest alternation is not picking the longest match which is a >>> bug. >>> >> This is not a bug. `||` is by design not declarative, and so only the first >> branch of it is significant for LTM purposes. This behavior can be confirmed >> by re-ordering the imperative alternation: >> >>> "42" ~~ / [ "0" || "42" ] | "4" / >> ｢4｣ >>> "42" ~~ / [ "42" || "0" ] | "4" / >> ｢42｣ >> >> Therefore, the longest declarative match is 4, and so that is the branch >> that LTM selects. Since there's no anchoring, there's furthermore no reason >> for it to backtrack into the second branch of the `|` to try the other `||` >> branch. >> >> I'm pretty sure this behavior is relied upon in the Perl 6 grammar itself; >> off the top of my head, it shows up in a bunch of places for the sake of >> error handling. >> >> So, working as designed. >> >> Thanks, >> >> /jnthn >> -- Will "Coke" Coleda
