Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

exhaustive capture too greedy (Or bogus test?) #4227

Open
p6rt opened this issue May 7, 2015 · 3 comments
Open

exhaustive capture too greedy (Or bogus test?) #4227

p6rt opened this issue May 7, 2015 · 3 comments
Labels

Comments

@p6rt
Copy link

p6rt commented May 7, 2015

Migrated from rt.perl.org#125133 (status was 'open')

Searchable as RT125133$

@p6rt
Copy link
Author

p6rt commented May 7, 2015

@p6rt
Copy link
Author

p6rt commented May 6, 2016

From @smls

I think this may be a dubious test rather than a Rakudo bug.

For reference, the code tested by the fudged test in question boils down to this​:

  ➜ say "abbb" ~~ m​:ex/"a" b+/;
  (「abbb」 「abb」 「ab」)

The test then checks if the first element of the result is "ab", and the second is "abb" - which is not the case because they are returned in the opposite order.

Why is the test assuming that the results with the same starting position have to be returned in a specific order? S05 specifically states that the order is not defined in such a case​:

  The matches are guaranteed to be returned in left-to-right order with respect
  to the starting positions. The order within each starting position is not
  guaranteed and may depend on the nature of both the pattern and the matching
  engine. (Conjecture​: or we could enforce backtracking engine semantics. Or we
  could guarantee no order at all unless the pattern starts with "​::" or some
  such to suppress DFAish solutions.)

(FYI​: Rakudo's current behavior seems to implement the "enforce backtracking engine semantics" conjecture.)

It looks to me like the test should sort the results, before checking that the first two are "ab" and "abb".

@p6rt
Copy link
Author

p6rt commented May 6, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant