~ in regexes shouldn't cause thrown exceptions

[p6rt]

Migrated from rt.perl.org#62086 (status was 'resolved')

Searchable as RT62086$

[p6rt]

From @moritz

Rakudo r35221​:

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

'x(ab' !~~ m/\/; 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/

[p6rt]

From @moritz

Rakudo r35221​:

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

'x(ab' !~~ m/\/; 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/

[p6rt]

From @masak

\ rakudo​: say '(foo' ~~ / '(' ~ ')' [foo] / \ rakudo 5e5969​: OUTPUT«Unable to parse _block48, couldn't find final ')' [...] \ why does everything in regexes indicate falure with a False-valued $/, except for goals, which indicate failure by throwing an exception? \ maybe should return failure instead of throwing exception \ yes, please. \ 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. \ I'll have to think a bit about how to pull that off. But feel free to file this as a ticket :) \ gladly. * masak submits rakudobug \ well, I can certainly get it to fail the match. I'm not sure where the message goes, though.

[p6rt]

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

[p6rt]

From @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. \ in effect, that gives grammars three possible outcomes​: success, failure, or death-because-of-failgoal. \ oh, I've kvetched about that before, it seems​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=62086 \ masak​: Why can't it be caught with a CATCH? \ masak​: Also, you're free to override FAILGOAL... \ I don't rightly know why it can't be. I'm having trouble reproducing the error in golfed code. \ m​: grammar G { regex TOP { a ~ c \ }; regex foo { b } }; say ?G.parse("abbc"); CATCH { when X​::AdHoc { say "caught" } } \ rakudo-moar 20aa85​: OUTPUT«caught␤» \ ok, here I *could* catch it. weird. \ 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 \ Of course, I guess we could have a default FAILGOAL that just fails and override it with one that throws. \ 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. \ and not just "we need to convey an error message here, so throwing an exception feels right" \ panic is another example \ categorically, it's still just a failed match. it feels like with the current setup, we're committing a category error. \ or rather, what precise thing is it that makes a parse failure so severe that it promotes from "falsy" to "die"? \ right now, from what I can see, the need to attach an error message. \ 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. \ oh, right. control flow. \ 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. \ Then don't use ~ \ I suppose.

[p6rt]

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

[p6rt]

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

[p6rt]

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.

[p6rt]

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