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

Open
p6rt opened this issue May 29, 2017 · 4 comments

Comments

@p6rt
Copy link

@p6rt p6rt commented May 29, 2017

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

Searchable as RT131397$

@p6rt
Copy link
Author

@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​:
https://gist.github.com/thundergnat/d6dd2d319afc71ee16234c58b3883f0f

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
  $r
};

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 https://irclog.perlgeek.de/perl6/2017-05-29#i_14654879

<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​:
https://gist.github.com/thundergnat/d6dd2d319afc71ee16234c58b3883f0f
<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​: «IntStr.new(1, "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 :-)

@p6rt
Copy link
Author

@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​:
https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130947

@p6rt
Copy link
Author

@p6rt p6rt commented May 31, 2017

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

@p6rt
Copy link
Author

@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
Projects
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.