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

semicolon subscripting in multi dim arrays has odd interactions with numeric string indexes #6274

p6rt opened this issue May 29, 2017 · 4 comments


Copy link

@p6rt p6rt commented May 29, 2017

Migrated from (status was 'open')

Searchable as RT131397$

Copy link

@p6rt p6rt commented May 29, 2017

From @thundergnat

Semicolon subscripting in multi dim arrays has odd interactions with
indexes that are numeric strings ( but not IntStrings )

See gist​:

sub d(*@​d) {
  #say @​d; # Debugging
  my @​a = [0, 1], [1, 0];
  my $r = 0;
  for @​d -> $c {
  $r = @​a[$r;$c]
  print $r.WHAT.gist, ', '; # Debugging

say d( (1,1,0).List );
say d( (1,1,0).Seq );
say d( (1,1,0).Array );
say d( [1,1,0] );
say d( <1 1 0> );
say d( 1,1,0 );
say d( 110.comb ); # WAT

See IRClogs around

<thundergnat> Hmmm. Don't know if this rises to the level of a bug, it
it is certainly a WAT at least to me.
<thundergnat> m​:
<camelia> rakudo-moar 608e88​: OUTPUT​: «(Int), 0␤(Int), 0␤(Int), 0␤(Int),
0␤(Int), 0␤(Int), 0␤(List), (1)␤»
<lizmat> hmmm.. I guess we could have a .comb candidate for Int that
would generate Int's
<lizmat> but that feels a bit too magic
<thundergnat> lizmat​: The weird thing is that the d sub gets an array
from .comb like every other instance, it just treats the array
subindexing differently.
<lizmat> because it gets Str as indexes
<thundergnat> as does <1 1 0> but _that_ works as expected...
<lizmat> thundergnat​: but those are IntStr's
<lizmat> so they use the Int candidate
<thundergnat> erm... Good point.
<lizmat> m​: dd <1>, "1"
<camelia> rakudo-moar 608e88​: OUTPUT​: «, "1")␤"1"␤»
<thundergnat> Anyway, As I said not really a bug, but it confused me for
about 15 minutes today.
<lizmat> thundergnat​: I think this WAT warrants a rakudobug fwiw
<lizmat> it shouldn't make a difference
<thundergnat> Want me to rakudobug it?
<thundergnat> lizmat The other odd thing; if I do the subscripting as
@​d[$r][$c] ( rather than @​d[$r;$c] ) it works as expected in all cases.
<lizmat> yeah, so the [;] candidate handles Str differently
<lizmat> definitely rakudobug this :-)

Copy link

@p6rt p6rt commented May 31, 2017

From @smls

Shorter example​:

  my @​a = [2, 4], [6, 8];
  say @​a[1; 1].perl; # 8
  say @​a["1"; "1"].perl; # (8,)

PS​: Definitely seems related to the following ticket​:

Copy link

@p6rt p6rt commented May 31, 2017

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

Copy link

@p6rt p6rt commented Jun 12, 2017

From @zoffixznet

m​: dd (<a b>,)[0;1] rakudo-moar bdf201​: OUTPUT​: «"b"␤»
m​: dd (<a b>,)[0;"1"] rakudo-moar bdf201​: OUTPUT​: «("b",)␤»

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.