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

make :%hash<key> a pair constructor #4997

Open
p6rt opened this issue Jan 5, 2016 · 5 comments
Open

make :%hash<key> a pair constructor #4997

p6rt opened this issue Jan 5, 2016 · 5 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented Jan 5, 2016

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

Searchable as RT127165$

@p6rt
Copy link
Author

p6rt commented Jan 5, 2016

From @FROGGS

For a while we can create Pairs from named captures of match variables​:
m​: my %hash = key => 42; say (​:$<key>)
rakudo-moar ac4f9f​: OUTPUT«key => Nil␤»

Sadly, this does not even parse​:
m​: my %hash = key => 42; say (​:$/<key>)
rakudo-moar ac4f9f​: OUTPUT«===SORRY!=== Error while compiling
/tmp/3GMq24eXRj␤Bogus statement␤at /tmp/3GMq24eXRj​:1␤------> my %hash =
key => 42; say (​:$⏏/<key>)␤ expecting any of​:␤ colon pair␤»

Nor does this create a Pair​:
m​: my %hash = key => 42; say (​:%hash<key>)
rakudo-moar ac4f9f​: OUTPUT«(Mu)␤»

So I vote for all shown statements to create a Pair of key => Nil or key
=> Any respectively.

Funnily, Arrays behave differently when used with colonpair syntax​:
m​: my @​array = 42, 43; say (​:@​array[0])
rakudo-moar ac4f9f​: OUTPUT«array => [42 43]␤»

Which is also wrong, IMO.
This case should either produce 0 => 42, or array => 42.
If we go for the latter then the shown Hashes should also be treated as
subscripts, and produce hash => 42, if the variable is not anonymous
like in $/&lt;key&gt; or $&lt;key>.
This would allow %hash<key foo>, but then again $&lt;key foo&gt; and $/<key
foo> need to parsefail.

@p6rt
Copy link
Author

p6rt commented Jan 5, 2016

From @LLFourn

Is the first example meant to be like​:

'"foo" ~~ /$<key>=.+/; say (​:$<key>)'

??

On Tue, Jan 5, 2016 at 6​:42 PM Tobias Leich <perl6-bugs-followup@​perl.org>
wrote​:

# New Ticket Created by Tobias Leich
# Please include the string​: [perl #​127165]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=127165 >

For a while we can create Pairs from named captures of match variables​:
m​: my %hash = key => 42; say (​:$<key>)
rakudo-moar ac4f9f​: OUTPUT«key => Nil␤»

Sadly, this does not even parse​:
m​: my %hash = key => 42; say (​:$/<key>)
rakudo-moar ac4f9f​: OUTPUT«===SORRY!=== Error while compiling
/tmp/3GMq24eXRj␤Bogus statement␤at /tmp/3GMq24eXRj​:1␤------> my %hash =
key => 42; say (​:$⏏/<key>)␤ expecting any of​:␤ colon pair␤»

Nor does this create a Pair​:
m​: my %hash = key => 42; say (​:%hash<key>)
rakudo-moar ac4f9f​: OUTPUT«(Mu)␤»

So I vote for all shown statements to create a Pair of key => Nil or key
=> Any respectively.

Funnily, Arrays behave differently when used with colonpair syntax​:
m​: my @​array = 42, 43; say (​:@​array[0])
rakudo-moar ac4f9f​: OUTPUT«array => [42 43]␤»

Which is also wrong, IMO.
This case should either produce 0 => 42, or array => 42.
If we go for the latter then the shown Hashes should also be treated as
subscripts, and produce hash => 42, if the variable is not anonymous
like in $/&lt;key&gt; or $&lt;key>.
This would allow %hash<key foo>, but then again $&lt;key foo&gt; and $/<key
foo> need to parsefail.

@p6rt
Copy link
Author

p6rt commented Jan 5, 2016

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

@p6rt
Copy link
Author

p6rt commented Jan 5, 2016

From @FROGGS

Yes, that's how you get a Match variable.

@p6rt
Copy link
Author

p6rt commented Jan 5, 2016

From @LLFourn

I was confused because of the preceding hash assignment :)

I also find myself not wanting to do { long-attribute-name =>
$obj.long-attribute-name }. Maybe $obj.=>long-attribute-name could DWIM and
:$obj.my-val becomes ('obj' => 'my-val result').

I'll be quiet now.

On Tue, Jan 5, 2016 at 7​:01 PM Tobias Leich <email@​froggs.de> wrote​:

Yes, that's how you get a Match variable.

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

No branches or pull requests

1 participant