[perl #62086] ~ in regexes shouldn't cause thrown exceptions

[Carl Mäsak via RT]

On Mon May 11 05:26:45 2015, pmichaud wrote:
 After discussion with jnthn at OSDC.no, here's what we propose:
 
 In the regex engine, the default FAILGOAL behavior should be to simply
 fail/backtrack.  This would be the default behavior for (rakudo)
 Cursor as well.
 
 Grammars that wish to have the generate-an-exception behavior can
 override FAILGOAL to do so.  The HLL::Grammar class (in NQP) will do
 this, meaning that Rakudo's grammar will still inherit/retain the
 throw-an-exception behavior.
 
 Part of our reasoning (which may be faulty) for this approach is that
 it's relatively easy to override FAILGOAL in a grammar but harder to
 do so for regexes that aren't in a grammar.  In the latter case
 (regex), it's more likely that you want simple backtracking rather
 than the throw an error message, so that should be the default.

This sounds very sane. +1

[perl #62086] ~ in regexes shouldn't cause thrown exceptions

[Carl Mäsak via RT]

masak as an author of grammars, I still find it annoying and difficult that 
grammars generally fail, that is, return a failing match -- *unless* you use 
the `~` combinator, in which case they nqp::die with an exception that can't be 
properly caught using a CATCH.
masak in effect, that gives grammars three possible outcomes: success, 
failure, or death-because-of-failgoal.
masak oh, I've kvetched about that before, it seems: 
https://rt.perl.org/Ticket/Display.html?id=62086
jnthn masak: Why can't it be caught with a CATCH?
jnthn masak: Also, you're free to override FAILGOAL...
masak I don't rightly know why it can't be. I'm having trouble reproducing 
the error in golfed code.
masak m: grammar G { regex TOP { a ~ c foo }; regex foo { b } }; say 
?G.parse(abbc); CATCH { when X::AdHoc { say caught } }
camelia rakudo-moar 20aa85: OUTPUT«caught␤»
masak ok, here I *could* catch it. weird.
jnthn In all the cases we use it for in the Perl 6 grammar, it'd be useless 
if it didn't throw, fwiw.
* masak adds that to the ticket
jnthn Of course, I guess we could have a default FAILGOAL that just fails and 
override it with one that throws.
masak if all outcomes of a grammar return a failed Match object *except* for 
FAILGOAL, then I'd like there to be a good theoretical explanation for FAILGOAL 
behaving differently.
masak and not just we need to convey an error message here, so throwing an 
exception feels right
jnthn panic is another example
masak categorically, it's still just a failed match. it feels like with the 
current setup, we're committing a category error.
masak or rather, what precise thing is it that makes a parse failure so 
severe that it promotes from falsy to die?
masak right now, from what I can see, the need to attach an error message.
jnthn That, and also wanting to give up at that point because there's no sane 
way to proceed and you'd never want something further up to try another path.
masak oh, right. control flow.
masak still, a use case I mention in earlier parts of that ticket is I just 
want to parse something in order to find out whether it's valid or not. having 
to deal with three-valued logic in that case is just... cruft.
jnthn Then don't use ~
masak I suppose.