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

Match.caps is inconsistent across backends #3753

Open
p6rt opened this issue Mar 22, 2015 · 3 comments
Open

Match.caps is inconsistent across backends #3753

p6rt opened this issue Mar 22, 2015 · 3 comments
Labels

Comments

@p6rt
Copy link

@p6rt p6rt commented Mar 22, 2015

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

Searchable as RT124150$

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Mar 22, 2015

From @peschwa

19​:57 <psch> j​: say ("a" ~~ /<alpha> & <ident> & <alnum>/).caps
19​:57 <camelia> rakudo-jvm 5778e8​: OUTPUT«ident => 「a」 alnum => 「a」 alpha => 「a」␤»
19​:57 <psch> m​: say ("a" ~~ /<alpha> & <ident> & <alnum>/).caps
19​:57 <camelia> rakudo-moar 5778e8​: OUTPUT«alpha => 「a」 ident => 「a」 alnum => 「a」␤»

I'm not sure what the correct result would be. S05 mentions that there should be a warning with overlapping bindings. Additionally, sorting of captures is supposed to be by the sub-Matches .from, but it's not clarified what happens to elements with the value for .from. In any case, the current behavior makes at least a few tests S05-capture/caps.t underspecific, e.g.

not ok 36 - .caps & - multiple terms# TODO & caps on jvm
use of uninitialized value of type Any in string context in sub proclaim at lib/Test.pm​:466

# Failed test '.caps & - multiple terms'
# at lib/Test.pm line
# expected​: 'alpha​:a|ident​:a'
# got​: 'ident​:a|alpha​:a'

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Dec 3, 2017

From @AlexDaniel

As of today (2017.11,HEAD(e5b660e)) it prints a *third* variant​:

(ident => 「a」 alpha => 「a」 alnum => 「a」)

The change happened in (2017-02-22) rakudo/rakudo@1cafc67

To me it tells that it is just random.

On 2015-03-22 13​:02​:12, peschwa@​gmail.com wrote​:

19​:57 <psch> j​: say ("a" ~~ /<alpha> & <ident> & <alnum>/).caps
19​:57 <camelia> rakudo-jvm 5778e8​: OUTPUT«ident => 「a」 alnum => 「a」
alpha => 「a」␤»
19​:57 <psch> m​: say ("a" ~~ /<alpha> & <ident> & <alnum>/).caps
19​:57 <camelia> rakudo-moar 5778e8​: OUTPUT«alpha => 「a」 ident => 「a」
alnum => 「a」␤»

I'm not sure what the correct result would be. S05 mentions that there
should be a warning with overlapping bindings. Additionally, sorting
of captures is supposed to be by the sub-Matches .from, but it's not
clarified what happens to elements with the value for .from. In any
case, the current behavior makes at least a few tests S05-
capture/caps.t underspecific, e.g.

not ok 36 - .caps & - multiple terms# TODO & caps on jvm
use of uninitialized value of type Any in string context in sub
proclaim at lib/Test.pm​:466

# Failed test '.caps & - multiple terms'
# at lib/Test.pm line
# expected​: 'alpha​:a|ident​:a'
# got​: 'ident​:a|alpha​:a'

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Dec 3, 2017

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

@p6rt p6rt added the weird label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.