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
Odd issue with chained assignments and reference to array #4323
Comments
From @hoelzroThere's a bug such that the following doesn't work as expected: my $value = @!values[0] = @!values.pop; -Rob |
From @hoelzrouse v6; plan 1; class BinaryHeap { method push($value) { method pop { if @!values == 1 { my BinaryHeap $heap .= new; |
From @usev6I wouldn't be surprised if this is the same problem as in ticket 80614 (https://rt-archive.perl.org/perl6/Ticket/Display.html?id=80614). There also doing something seemingly unrelated changes the behaviour of the chained assignment. |
@usev6 - Status changed from 'new' to 'open' |
From @hoelzroWith this bug, it seems that the following chained assignment: my $value = @values[0] = @values.pop; is generated using left-associativity instead of right-associativity. |
From @hoelzrouse v6; plan 1; my @values = 84, 85; if False { # note how this never runs # changing this line... is $value, @values[0], '$value and @values[0] should be equal'; |
From @hoelzroOn 2015-06-14 08:21:39, rob@hoelz.ro wrote:
Alright, I managed to figure out the problem last night. The issue is that the operator precedence table from HLL::Grammar (used for both Grammar.O and Grammar.EXPR) has a hash of hashes, the values of which specify things like precedence and associativity. For example, the hash contains something like the following for the key '%list_assignment': { :prec<i=>, :assoc<right>, :sub<e=> } The 'sub' key is the...umm, key here. After handling some things with %inO<prec> in HLL::Grammar.EXPR, %inO<sub> is assigned to %inO<prec> - changing the precedence of list assignment from 'i=' to 'e=' *globally*. Changing HLL::Grammar to create a copy of the shared precedence hash fixes the problem; however, it also causes other, more essential features, like signatures and list assignment (but interestingly enough, not list initialization!) to fail in spectacular ways. |
@hoelzro - Status changed from 'new' to 'resolved' |
Migrated from rt.perl.org#125407 (status was 'resolved')
Searchable as RT125407$
The text was updated successfully, but these errors were encountered: