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

Range.rotor and List.rotor behave differently (^11 .rotor: 1.5) #5104

Closed
p6rt opened this issue Jan 29, 2016 · 5 comments
Closed

Range.rotor and List.rotor behave differently (^11 .rotor: 1.5) #5104

p6rt opened this issue Jan 29, 2016 · 5 comments

Comments

@p6rt
Copy link

@p6rt p6rt commented Jan 29, 2016

Migrated from rt.perl.org#127424 (status was 'resolved')

Searchable as RT127424$

@p6rt
Copy link
Author

@p6rt p6rt commented Jan 29, 2016

From @AlexDaniel

Code​:
say <a b c d e f g h i j k>.rotor​: 1.5

Result​:
((a b) (b c) (d e) (e f) (g h) (h i) (j k))

Hmm, I'm not sure if this was intended to work, but​:

Code​:
say ^11 .rotor​: 1.5

Result​:
This type cannot unbox to a native integer
  in block <unit> at -e line 1

My biggest problem with this is that it is not consistent.

<perlpilot> AlexDaniel​: IMHO, any non-Int values for the number of items to
  take/skip should be considered an error. Maybe Inf
could be used
  for "take the rest" or "skip the rest", but
otherwise non-Int
  should error.
<AlexDaniel> perlpilot​: but it's an interesting feature
<ZoffixW> perlpilot, why error and not just .Int?
<ZoffixW> m​: say <a b c d e f g h i j k>[1..1.5], (^10)[1..1.5]
<camelia> rakudo-moar 780192​: OUTPUT«(b)(1)␤»
<perlpilot> m​: say <a b c d e f g h i j k>.rotor​: 2 => -1, 2 => 0; # Much
much MUCH clearer than .rotor​: 1.5
<camelia> rakudo-moar 780192​: OUTPUT«((a b) (b c) (d e) (e f) (g h) (h i)
(j k))␤»
<perlpilot> ZoffixW​: because I favor explicit over implicit when there's
the potential for ambiguity.

So, having fractional counts is not required. Either we throw an error (a
meaningful one) or we just .Int it. Whether it should do one or another is
non-obvious, see this discussion​:
http://irclog.perlgeek.de/perl6/2016-01-29#i_11960287

Same problem also appears on RHS of a pair​:

Code​:
say <a b c d e f g h i j k>.rotor​: 1 => 0.5

Result​:
((a) (b) (d) (e) (g) (h) (j))

But

Code​:
say ^10 .rotor​: 1 => 0.5

Result​:
===SORRY!===
This type cannot unbox to a native integer

This time it is a compile-time error (without a line number!), not run
time. How weird.

@p6rt
Copy link
Author

@p6rt p6rt commented Feb 3, 2016

From @skids

Note that the examples above have changed behavior to note the precedence mistake​:

$ perl6 -e '^11.say'
Potential difficulties​:
  Precedence of ^ is looser than method call; please parenthesize
  at -e​:1
  ------> ^11.say
WARNINGS for -e​:
Useless use of "^" in expression "^11.say" in sink context (line 1)
11
$ perl6 -e '^11.rotor(2)'
Potential difficulties​:
  Precedence of ^ is looser than method call; please parenthesize
  at -e​:1
  ------> ^11.rotor(2)
WARNINGS for -e​:
Useless use of "^" in expression "^11.rotor(2)" in sink context (line 1)
$ perl6 -e '^11.rotor(1.5)'
Potential difficulties​:
  Precedence of ^ is looser than method call; please parenthesize
  at -e​:1
  ------> ^11.rotor(1.5)
WARNINGS for -e​:
Useless use of "^" in expression "^11.rotor(1.5)" in sink context (line 1)

...but the meat of the ticket is still valid​:

$ perl6 -e '(^11).rotor(1.5)'
This type cannot unbox to a native integer
  in block <unit> at -e line 1

$ perl6 -e 'say (0,1,2,3,4,5,6,7,8,9,10).rotor(1.5)'
((0 1) (1 2) (3 4) (4 5) (6 7) (7 8) (9 10))

$ perl6 -e 'say (^11).flat.rotor(1.5)'
This type cannot unbox to a native integer
  in block <unit> at -e line 1

$ perl6 -e 'say (^11).list.rotor(1.5)'
This type cannot unbox to a native integer
  in block <unit> at -e line 1

$ perl6 -e 'say (^11).List.rotor(1.5)'
This type cannot unbox to a native integer
  in block <unit> at -e line 1

@p6rt
Copy link
Author

@p6rt p6rt commented Feb 3, 2016

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

@p6rt
Copy link
Author

@p6rt p6rt commented Aug 1, 2016

From @zoffixznet

Thanks for the report.

Fixed in rakudo/rakudo@59f040d
Tests added in Raku/roast@7ff9f7c

--
Cheers,
ZZ | https://twitter.com/zoffix

@p6rt
Copy link
Author

@p6rt p6rt commented Aug 1, 2016

@zoffixznet - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this Aug 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant