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

Can't store whole 1&2 junctions in Mu-keyed hash in Rakudo #4401

Open
p6rt opened this issue Jul 14, 2015 · 5 comments
Open

Can't store whole 1&2 junctions in Mu-keyed hash in Rakudo #4401

p6rt opened this issue Jul 14, 2015 · 5 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Jul 14, 2015

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

Searchable as RT125614$

@p6rt
Copy link
Author

p6rt commented Jul 14, 2015

From @masak

<jnthn> my %h{Mu}; # now you can store objects as keys
<jnthn> m​: my %xy{Mu};
<camelia> rakudo-moar dd3bcc​: ( no output )
<jnthn> Note the keys there are objects, not strings.
<moritz> m​: my %xy{Mu}; %xy{1&2} = 3; say %xy.perl
<camelia> rakudo-moar ccb41d​: OUTPUT«Hash[Any,Mu].new(1 => 3, 2 => 3)␤»
<moritz> bug
<jnthn> hah...I wonder if the postcircumfix sub is to blame...
* masak submits rakudobug

@p6rt
Copy link
Author

p6rt commented Jul 15, 2015

From @lizmat

On 14 Jul 2015, at 12​:29, Carl Mäsak (via RT) <perl6-bugs-followup@​perl.org> wrote​:

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

<jnthn> my %h{Mu}; # now you can store objects as keys
<jnthn> m​: my %xy{Mu};
<camelia> rakudo-moar dd3bcc​: ( no output )
<jnthn> Note the keys there are objects, not strings.
<moritz> m​: my %xy{Mu}; %xy{1&2} = 3; say %xy.perl
<camelia> rakudo-moar ccb41d​: OUTPUT«Hash[Any,Mu].new(1 => 3, 2 => 3)␤»
<moritz> bug
<jnthn> hah...I wonder if the postcircumfix sub is to blame...
* masak submits rakudobug

Some more tests​:
[22​:14​:53] <lizmat> Looking at #​125614 now​:
[22​:15​:02] <lizmat> m​: my %xy{Mu}; %xy{1&2} = 3; say %xy.perl # wrong
[22​:15​:02] <+camelia> rakudo-moar 8957fc​: OUTPUT«Hash[Any,Mu].new(1 => 3, 2 => 3)␤»
[22​:15​:25] <lizmat> m​: my %xy{Mu}; %xy.AT-KEY(1&2) = 3; say %xy.perl # is this right?
[22​:15​:25] <+camelia> rakudo-moar 8957fc​: OUTPUT«Hash[Any,Mu].new(all(1 => 3, 2 => 3))␤»
[22​:15​:43] <lizmat> m​: my %xy{Mu}; %xy.ASSIGN-KEY(1&2,3); say %xy.perl # is this right?
[22​:15​:43] <+camelia> rakudo-moar 8957fc​: OUTPUT«Hash[Any,Mu].new(all(1 => 3, 2 => 3))␤»
[22​:16​:20] <lizmat> m​: my %xy{Mu}; %xy.BIND-KEY(1&2,3); say %xy.perl # and this?
[22​:16​:21] <+camelia> rakudo-moar 8957fc​: OUTPUT«Hash[Any,Mu].new(all(1 => 3, 2 => 3))␤»
[22​:17​:53] <ShimmerFairy> Hm. Unless there's something in the specs stating otherwise, I'd think %xy{1&2} = 3 would make 1 => 3, 2 => 3 , since it is a Junction
[22​:17​:53] <lizmat> m​: my %xy{Any}; %xy{1&2} = 3; say %xy.perl # and this?
[22​:17​:53] <+camelia> rakudo-moar 8957fc​: OUTPUT«Hash[Any,Any].new(1 => 3, 2 => 3)␤»
[22​:17​:57] <ShimmerFairy> m​: sub foo($a) { say $a }; foo(1&2)
[22​:17​:58] <+camelia> rakudo-moar 8957fc​: OUTPUT«1␤2␤»
[22​:18​:18] <ShimmerFairy> ^ that's my reason for thinking {1&2} is the one doing the right thing.
[22​:18​:58] <lizmat> not if it is a typed hash with Mu​: then the autothreading should not work (is what conception of the problem is)
[22​:20​:58] <ShimmerFairy> Oh, I see. Well, I think in that case it should be any(1, 2) => 3 , since the Junction is the key (I don't think all(1 => 3, 2 => 3) is right, and I don't see how it could be immediately)

So, assuming AT-KEY is doing the right thing, and looking at the circumfix {} code​:

multi sub postcircumfix​:<{ }>( \SELF, \key ) is rw {
  SELF.AT-KEY(key);
}

Since we bind the key value to what is being passed to AT-KEY, and AT-KEY is doing the right thing, I can only assume there is something screwy going on with “is rw”. And that is going right into the bowels, and I’m out of my league :-)

Hope this helps.

Liz

@p6rt
Copy link
Author

p6rt commented Jul 15, 2015

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

@p6rt
Copy link
Author

p6rt commented Dec 1, 2017

From @AlexDaniel

Still reproducible (2017.11, HEAD(5929887))

On 2015-07-14 22​:32​:47, elizabeth wrote​:

On 14 Jul 2015, at 12​:29, Carl Mäsak (via RT) <perl6-bugs-
followup@​perl.org> wrote​:

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

<jnthn> my %h{Mu}; # now you can store objects as keys
<jnthn> m​: my %xy{Mu};
<camelia> rakudo-moar dd3bcc​: ( no output )
<jnthn> Note the keys there are objects, not strings.
<moritz> m​: my %xy{Mu}; %xy{1&2} = 3; say %xy.perl
<camelia> rakudo-moar ccb41d​: OUTPUT«Hash[Any,Mu].new(1 => 3, 2 =>
3)␤»
<moritz> bug
<jnthn> hah...I wonder if the postcircumfix sub is to blame...
* masak submits rakudobug

Some more tests​:
[22​:14​:53] <lizmat> Looking at #​125614 now​:
[22​:15​:02] <lizmat> m​: my %xy{Mu}; %xy{1&2} = 3; say %xy.perl #
wrong
[22​:15​:02] <+camelia> rakudo-moar 8957fc​: OUTPUT«Hash[Any,Mu].new(1
=> 3, 2 => 3)␤»
[22​:15​:25] <lizmat> m​: my %xy{Mu}; %xy.AT-KEY(1&2) = 3; say
%xy.perl # is this right?
[22​:15​:25] <+camelia> rakudo-moar 8957fc​:
OUTPUT«Hash[Any,Mu].new(all(1 => 3, 2 => 3))␤»
[22​:15​:43] <lizmat> m​: my %xy{Mu}; %xy.ASSIGN-KEY(1&2,3); say
%xy.perl # is this right?
[22​:15​:43] <+camelia> rakudo-moar 8957fc​:
OUTPUT«Hash[Any,Mu].new(all(1 => 3, 2 => 3))␤»
[22​:16​:20] <lizmat> m​: my %xy{Mu}; %xy.BIND-KEY(1&2,3); say
%xy.perl # and this?
[22​:16​:21] <+camelia> rakudo-moar 8957fc​:
OUTPUT«Hash[Any,Mu].new(all(1 => 3, 2 => 3))␤»
[22​:17​:53] <ShimmerFairy> Hm. Unless there's something in the
specs stating otherwise, I'd think %xy{1&2} = 3 would make 1 => 3, 2
=> 3 , since it is a Junction
[22​:17​:53] <lizmat> m​: my %xy{Any}; %xy{1&2} = 3; say %xy.perl #
and this?
[22​:17​:53] <+camelia> rakudo-moar 8957fc​: OUTPUT«Hash[Any,Any].new(1
=> 3, 2 => 3)␤»
[22​:17​:57] <ShimmerFairy> m​: sub foo($a) { say $a }; foo(1&2)
[22​:17​:58] <+camelia> rakudo-moar 8957fc​: OUTPUT«1␤2␤»
[22​:18​:18] <ShimmerFairy> ^ that's my reason for thinking {1&2}
is the one doing the right thing.
[22​:18​:58] <lizmat> not if it is a typed hash with Mu​: then the
autothreading should not work (is what conception of the problem is)
[22​:20​:58] <ShimmerFairy> Oh, I see. Well, I think in that case
it should be any(1, 2) => 3 , since the Junction is the key (I don't
think all(1 => 3, 2 => 3) is right, and I don't see how it could be
immediately)

So, assuming AT-KEY is doing the right thing, and looking at the
circumfix {} code​:

multi sub postcircumfix​:<{ }>( \SELF, \key ) is rw {
SELF.AT-KEY(key);
}

Since we bind the key value to what is being passed to AT-KEY, and AT-
KEY is doing the right thing, I can only assume there is something
screwy going on with “is rw”. And that is going right into the
bowels, and I’m out of my league :-)

Hope this helps.

Liz

@p6rt
Copy link
Author

p6rt commented Dec 14, 2017

From @zoffixznet

On Tue, 14 Jul 2015 22​:32​:47 -0700, elizabeth wrote​:

On 14 Jul 2015, at 12​:29, Carl Mäsak (via RT) <perl6-bugs-
followup@​perl.org> wrote​:

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

<jnthn> my %h{Mu}; # now you can store objects as keys
<jnthn> m​: my %xy{Mu};
<camelia> rakudo-moar dd3bcc​: ( no output )
<jnthn> Note the keys there are objects, not strings.
<moritz> m​: my %xy{Mu}; %xy{1&2} = 3; say %xy.perl
<camelia> rakudo-moar ccb41d​: OUTPUT«Hash[Any,Mu].new(1 => 3, 2 =>
3)␤»
<moritz> bug
<jnthn> hah...I wonder if the postcircumfix sub is to blame...
* masak submits rakudobug

Some more tests​:
[22​:14​:53] <lizmat> Looking at #​125614 now​:
[22​:15​:02] <lizmat> m​: my %xy{Mu}; %xy{1&2} = 3; say %xy.perl #
wrong
[22​:15​:02] <+camelia> rakudo-moar 8957fc​: OUTPUT«Hash[Any,Mu].new(1
=> 3, 2 => 3)␤»
[22​:15​:25] <lizmat> m​: my %xy{Mu}; %xy.AT-KEY(1&2) = 3; say
%xy.perl # is this right?
[22​:15​:25] <+camelia> rakudo-moar 8957fc​:
OUTPUT«Hash[Any,Mu].new(all(1 => 3, 2 => 3))␤»
[22​:15​:43] <lizmat> m​: my %xy{Mu}; %xy.ASSIGN-KEY(1&2,3); say
%xy.perl # is this right?
[22​:15​:43] <+camelia> rakudo-moar 8957fc​:
OUTPUT«Hash[Any,Mu].new(all(1 => 3, 2 => 3))␤»
[22​:16​:20] <lizmat> m​: my %xy{Mu}; %xy.BIND-KEY(1&2,3); say
%xy.perl # and this?
[22​:16​:21] <+camelia> rakudo-moar 8957fc​:
OUTPUT«Hash[Any,Mu].new(all(1 => 3, 2 => 3))␤»
[22​:17​:53] <ShimmerFairy> Hm. Unless there's something in the
specs stating otherwise, I'd think %xy{1&2} = 3 would make 1 => 3, 2
=> 3 , since it is a Junction
[22​:17​:53] <lizmat> m​: my %xy{Any}; %xy{1&2} = 3; say %xy.perl #
and this?
[22​:17​:53] <+camelia> rakudo-moar 8957fc​: OUTPUT«Hash[Any,Any].new(1
=> 3, 2 => 3)␤»
[22​:17​:57] <ShimmerFairy> m​: sub foo($a) { say $a }; foo(1&2)
[22​:17​:58] <+camelia> rakudo-moar 8957fc​: OUTPUT«1␤2␤»
[22​:18​:18] <ShimmerFairy> ^ that's my reason for thinking {1&2}
is the one doing the right thing.
[22​:18​:58] <lizmat> not if it is a typed hash with Mu​: then the
autothreading should not work (is what conception of the problem is)
[22​:20​:58] <ShimmerFairy> Oh, I see. Well, I think in that case
it should be any(1, 2) => 3 , since the Junction is the key (I don't
think all(1 => 3, 2 => 3) is right, and I don't see how it could be
immediately)

So, assuming AT-KEY is doing the right thing, and looking at the
circumfix {} code​:

multi sub postcircumfix​:<{ }>( \SELF, \key ) is rw {
SELF.AT-KEY(key);
}

Since we bind the key value to what is being passed to AT-KEY, and AT-
KEY is doing the right thing, I can only assume there is something
screwy going on with “is rw”. And that is going right into the
bowels, and I’m out of my league :-)

Hope this helps.

Liz

I managed to fix[^1] this, though almost immediately using Junctions as keys caused
Map.sort to blow up. I fixed[^2] that too, but not sure what other crucial methods
explode due to Junction keys.

I aborted spectest when multiple failures occurred; not due to my fix, but rather due
to RT#​128905[^3]. I've no idea how to fix that ticket, so I've stashed my work for this
ticket into fix-Hash-Mu-keys--RT-1357201 branch[^4] for now. It still needs a full
spectest run before merge, once RT#​128905 is fixed.

[1] rakudo/rakudo@a5cf61c
[2] rakudo/rakudo@a5cf61c
[3] https://rt-archive.perl.org/perl6/Ticket/Display.html?id=128905#txn-1516048
[4] https://github.com/rakudo/rakudo/tree/fix-Hash-Mu-keys--RT-1357201

@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