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
Backtracking into a parameterized subrule like <meh(42)>
tries to call it without arguments.
#6120
Comments
From @AlexDanielHere are 3 examples that work as expected: Code: Result: Code Result: Code: Result: And here is one that doesn't: Code: Result: Why? What second argument is it expecting? |
From @MasterDuke17On Fri, 03 Mar 2017 20:25:27 -0800, alex.jakimenko@gmail.com wrote:
Some more examples [23:10] <MasterDuke> m: my regex meh($t, |
The RT System itself - Status changed from 'new' to 'open' |
From @smlsIt has to do with backtracking, because: 1) The problem disappears when `:ratchet` mode is enabled in the top-level regex: ➜ my regex meh ($t) { . }; 2) The problem disappears when the named regex is made a `token`: Of course, the regex engine could avoid backtracking entirely in that example, but maybe it's just not optimized enough to know that. my regex meh ($t) { say "abcde" ~~ / It outputs: meh start Note how the error message appears after having reached the end of the regex for the first time, just before it would have backtracked into `meh` for the first time. In comparison, when removing the parameterization of `meh`, the example prints the following (Note how it backtracked into `meh` four times, like it should): meh start In summary, what *appears* to be happening, is this: - If a named subrule is called with parameters... |
From @smlsSorry, copy-pasto in the second-to-last output listing. It is: meh start |
From @skidsThis is also an issue in nqp. $ nqp -e 'grammar f { regex TOP { ^ <foo(42)> $ }; regex foo($i) { .. } }; nqp::say(f.parse("aaa"));' Fixing it in nqp first is probably the best first step. To Currently, a Cursor will fill in its $!regexsub parameter by getting the If it finds code in $!restart, .cursor_next invokes it with no arguments. $ nqp -e 'grammar f { regex TOP { ^ <foo(42)> $ }; regex foo($i?) { {nqp::say($i)} .. } }; f.parse("aaa");' ...noting that the 42 is only said once on the first call where the There is also a cursor_more in NQP which seems to be unused in NQP, which In rakudo, cursor_next and cursor_more are replicated under different Long story short, it does not look like passing args along down Worth noting as a side note, it has been expressed before that having |
Migrated from rt.perl.org#130910 (status was 'open')
Searchable as RT130910$
The text was updated successfully, but these errors were encountered: