From @moritz

Rakudo r35221​:

regex t1 {
  '(' ~ ')' 'ab'
}

'x(ab' !~~ m/<t1>/;
say "done",

The regex match throws an exception because the final ')' isn't found
anywhere.
According to Larry, it shouldn't​:
http://irclog.perlgeek.de/perl6/2009-01-08#i_816425

This is tested in t/spec/S05-metachars/tilde.t (which I hope to enhance
soon).

Cheers,
Moritz

--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/

From @masak

<masak> rakudo​: say '(foo' ~~ / '(' ~ ')' [foo] /
<p6eval> rakudo 5e5969​: OUTPUT«Unable to parse _block48, couldn't find
final ')' [...]
<masak> why does everything in regexes indicate falure with a
False-valued $/, except for goals, which indicate failure by throwing
an exception?
<pmichaud> maybe should return failure instead of throwing exception
<masak> yes, please.
<masak> my real-world situation to back this up is a test file with a
grammar parse wrapped in a method call which checks whether the syntax
of an expression is correct. I only expect the method call to return a
Bool, not to blow up.
<pmichaud> I'll have to think a bit about how to pull that off. But
feel free to file this as a ticket :)
<masak> gladly.
* masak submits rakudobug
<pmichaud> well, I can certainly get it to fail the match. I'm not
sure where the message goes, though.

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

From @masak

<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-archive.perl.org/perl6/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.

From @pmichaud

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.

I propose to clean up the FAILGOAL API in NQP and Rakudo, then update S05 to match. Any objections or reactions would be welcomed.

Pm

From @masak

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

From @jnthn

On Tue May 12 06​:47​:23 2015, masak wrote​:

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

TimToaday++ approved also. I did the changes to implement the new semantics, and unfudged the existing tests for this ticket.

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