Re: [perl #129843] [LTA] Indexing on a Str throws generic “out of range” message which is less than awesome (“hello”[2])

[Brandon Allbery]

On Mon, May 8, 2017 at 4:49 PM, Joachim Durchholz  wrote:

> If the mental model for Perl6 strings is "array of characters" though


Perl has never had that mental model, is my point. It's generally imported
by folks who come from languages where strings *are* "arrays of characters"
--- and where that model has a strong tendency to cause problems. (See
Python 3's struggles with Unicode as an example. And C/C++, well, don't
even get me started. Bytes stopped being the basis of characters even
*before* Unicode. C and C++ are still struggling to understand that.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #129843] [LTA] Indexing on a Str throws generic “out of range” message which is less than awesome (“hello”[2])

[Joachim Durchholz]

Am 08.05.2017 um 20:59 schrieb Brandon Allbery:


On Mon, May 8, 2017 at 2:52 PM, Aleks-Daniel Jakimenko-Aleksejev via RT
> wrote:

Usually I'm against all perl5 error messages


This is a Pythonism (and C and other such languages).


Which doesn't mean that that's a bad thing.

It all comes down to whether you want the usual semantics of [] apply to 
character positions in a string.
If [] can to to the LHS, and Perl6 strings are immutable, then having [] 
would be a mistake.
If accessing individual characters in a string is a bad idea in general 
(a defensible position in the age of Unicode), then having [] for 
strings might be a bad idea even if you could otherwise implement that.


If the mental model for Perl6 strings is "array of characters" though, 
then having [] for uniformity is probably a good idea, and more 
important than keeping Perl5 restrictions.


Just my 2 cents from the sideline.
Disclaimer: I'm much more an Abstract Data Type guy than a Perl guy, so 
feel free to ignore because inappropriate.

Re: [perl #129843] [LTA] Indexing on a Str throws generic “out of range” message which is less than awesome (“hello”[2])

[Aleks-Daniel Jakimenko-Aleksejev]

Yes, but I was trying to address this part: “Just recall how often the
Perl-5-ism exceptions get thrown when writing normal Perl 6 code”

The idea, I guess, is that the proposed error message has the same level of
annoyingness as perl5-related error messages.

On Mon, May 8, 2017 at 9:59 PM, Brandon Allbery  wrote:

>
> On Mon, May 8, 2017 at 2:52 PM, Aleks-Daniel Jakimenko-Aleksejev via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
>> Usually I'm against all perl5 error messages
>
>
> This is a Pythonism (and C and other such languages). Older Perl has the
> same behavior that you can't index a string that way, but must use e.g.
> substr. You will *not* likely see this from old Perlers; they will reach
> for substr.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

Re: [perl #129843] [LTA] Indexing on a Str throws generic “out of range” message which is less than awesome (“hello”[2])

[Brandon Allbery]

On Mon, May 8, 2017 at 2:52 PM, Aleks-Daniel Jakimenko-Aleksejev via RT <
perl6-bugs-follo...@perl.org> wrote:

> Usually I'm against all perl5 error messages


This is a Pythonism (and C and other such languages). Older Perl has the
same behavior that you can't index a string that way, but must use e.g.
substr. You will *not* likely see this from old Perlers; they will reach
for substr.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

[perl #131273] [REGRESSION] .pick and .pickpairs with negative amounts ( say ^5 .BagHash.pickpairs(-2.5) )

[via RT]

# New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
# Please include the string:  [perl #131273]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131273 >


Not a big deal as it was changed yesterday, but still:

Code:
say ^5 .BagHash.pick(-2.5)

Result:
(3 0 1 4 2)


Code:
say ^5 .BagHash.pickpairs(-2.5)

Result:
Unable to allocate an array of 18446744073709551614 elements
  in block  at /tmp/p5a9fTqCqs line 1


For the last one, bisectable points to 
https://github.com/rakudo/rakudo/commit/0f21f511c5631545293c3d8812f8dcf5addd988f

This ticket is probably already resolved by lizmat++, but I thought I'll file 
it anyway so that it doesn't fall through the cracks (seems like there are no 
tests for these cases?).

[perl #129843] [LTA] Indexing on a Str throws generic “out of range” message which is less than awesome (“hello”[2])

[Aleks-Daniel Jakimenko-Aleksejev via RT]

I agree with you, but we can do better.

Usually I'm against all perl5 error messages, but I believe that this case is
different. I am sure that this is what most people attempt to do at some point.
I also know for sure that this is what I did a couple of times when I was
starting with Perl 6. I also remember many times people were asking this on the
channel.

So here's what I think:
* A FAQ entry can be added. I created a doc issue for this:
https://github.com/perl6/doc/issues/1300
* I think that it will be possible to add a compile-time error if you do
something like ｢‘foo’[2]｣. That is, if somebody attempts to index a string
literal, then we know for sure that it is wrong (… or at least, the error
message will do more good than harm).

On 2017-05-08 09:26:53, c...@zoffix.com wrote:
> On Mon, 10 Oct 2016 06:05:10 -0700, alex.jakime...@gmail.com wrote:
> > Code:
> > say “hello”[2]
> >
> > Result:
> > Index out of range. Is: 2, should be in 0..0
> > in block  at -e line 1
> >
> > Actually thrown at:
> > in block  at -e line 1
> >
> >
> >
> > IRC discussion starting here:
> > https://irclog.perlgeek.de/perl6/2016-10-10#i_13370830
>
>
> I don't get why we throw in this case at all. We don't do it with any
> of the Positionals:
>
>  m: say $_[42] for 1..1, (1,), [1,], (1,).Seq
>  rakudo-moar 60f898: OUTPUT: «Nil␤Nil␤(Any)␤Nil␤»
>
> Other than Blob and Uni, which I'd say also break the consistency:
>
>  m: say "".NFD[1]
>  rakudo-moar 60f898: OUTPUT: «Index out of range. Is: 1,
> should be in 0..-1␤ in block  at  line 1␤␤Actually thrown
> at:␤ in block  at  line 1␤␤»
>  m: say Blob.new[1]
>  rakudo-moar 60f898: OUTPUT: «Index out of range. Is: 1,
> should be in 0..-1␤ in block  at  line 1␤␤Actually thrown
> at:␤ in block  at  line 1␤␤»
>
> The throwage breaks the "everything is a 1-item list" idiom, as I
> can't safely do $x[1], because
> it'll explode any time $x is not a non-Stringy Positional. I tried to
> remove the throwage, but it's blocked by several 6.c tests.
>
> And regardless of that, I'm -1 on this ticket. Right now $x[1] throws
> X::OutOfRange on non-Positionals (even though it shouldn't), but the
> proposed fix for this ticket would see the possibility of yet another
> exception in another special case being thrown, all for the sake that
> *someone new to the language* *assumes* Perl 6 can index strings. IMO
> such special casing will be a hassle to more normal Perl 6 users than
> a helpful tip to new Perl 6 users. Just recall how often the Perl-5-
> ism exceptions get thrown when writing normal Perl 6 code.

Re: [perl #131272] .pickpairs .Int-ifes the argument, but .pick doesn't (say ^5 .BagHash.pick(2.5))

[Elizabeth Mattijsen]

Fixed with 31be51284e70badd8ed , tests needed.

> On 8 May 2017, at 20:25, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #131272]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131272 >
> 
> 
> Code:
> say ^5 .BagHash.pickpairs(2.5);
> 
> Result:
> (1 => 1 4 => 1)
> 
> 
> Code:
> say ^5 .BagHash.pick(2.5);
> 
> Result:
> count computed to 2.5, which cannot be used
>  in block  at  line 1
> 
> 
> I find it impossible to predict when non-Int args are alright and when they 
> are not. I would expect consistency of some sort.
> 
> (same thing with .grab and .grabpairs)

Re: [perl #131272] .pickpairs .Int-ifes the argument, but .pick doesn't (say ^5 .BagHash.pick(2.5))

[Elizabeth Mattijsen via RT]

Fixed with 31be51284e70badd8ed , tests needed.

> On 8 May 2017, at 20:25, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  wrote:
> 
> # New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
> # Please include the string:  [perl #131272]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131272 >
> 
> 
> Code:
> say ^5 .BagHash.pickpairs(2.5);
> 
> Result:
> (1 => 1 4 => 1)
> 
> 
> Code:
> say ^5 .BagHash.pick(2.5);
> 
> Result:
> count computed to 2.5, which cannot be used
>  in block  at  line 1
> 
> 
> I find it impossible to predict when non-Int args are alright and when they 
> are not. I would expect consistency of some sort.
> 
> (same thing with .grab and .grabpairs)

[perl #131272] .pickpairs .Int-ifes the argument, but .pick doesn't (say ^5 .BagHash.pick(2.5))

[via RT]

# New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
# Please include the string:  [perl #131272]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131272 >


Code:
say ^5 .BagHash.pickpairs(2.5);

Result:
(1 => 1 4 => 1)


Code:
say ^5 .BagHash.pick(2.5);

Result:
count computed to 2.5, which cannot be used
  in block  at  line 1


I find it impossible to predict when non-Int args are alright and when they are 
not. I would expect consistency of some sort.

(same thing with .grab and .grabpairs)

[perl #129843] [LTA] Indexing on a Str throws generic “out of range” message which is less than awesome (“hello”[2])

[Zoffix Znet via RT]

On Mon, 10 Oct 2016 06:05:10 -0700, alex.jakime...@gmail.com wrote:
> Code:
> say “hello”[2]
> 
> Result:
> Index out of range. Is: 2, should be in 0..0
>   in block  at -e line 1
> 
> Actually thrown at:
>   in block  at -e line 1
> 
> 
> 
> IRC discussion starting here:
> https://irclog.perlgeek.de/perl6/2016-10-10#i_13370830


I don't get why we throw in this case at all. We don't do it with any of the 
Positionals:

 m: say $_[42] for 1..1, (1,), [1,],  (1,).Seq
 rakudo-moar 60f898: OUTPUT: «Nil␤Nil␤(Any)␤Nil␤»

Other than Blob and Uni, which I'd say also break the consistency:

 m: say "".NFD[1]
 rakudo-moar 60f898: OUTPUT: «Index out of range. Is: 1, should be 
in 0..-1␤  in block  at  line 1␤␤Actually thrown at:␤  in block 
 at  line 1␤␤»
 m: say Blob.new[1]
 rakudo-moar 60f898: OUTPUT: «Index out of range. Is: 1, should be 
in 0..-1␤  in block  at  line 1␤␤Actually thrown at:␤  in block 
 at  line 1␤␤»

The throwage breaks the "everything is a 1-item list" idiom, as I can't safely 
do $x[1], because
it'll explode any time $x is not a non-Stringy Positional. I tried to remove 
the throwage, but it's blocked by several 6.c tests.

And regardless of that, I'm -1 on this ticket. Right now $x[1] throws 
X::OutOfRange on non-Positionals (even though it shouldn't), but the proposed 
fix for this ticket would see the possibility of yet another exception in 
another special case being thrown, all for the sake that *someone new to the 
language* *assumes* Perl 6 can index strings. IMO such special casing will be a 
hassle to more normal Perl 6 users than a helpful tip to new Perl 6 users. Just 
recall how often the Perl-5-ism exceptions get thrown when writing normal Perl 
6 code.

[perl #129843] [LTA] Indexing on a Str throws generic “out of range” message which is less than awesome (“hello”[2])

[Zoffix Znet via RT]

On Mon, 10 Oct 2016 06:05:10 -0700, alex.jakime...@gmail.com wrote:
> Code:
> say “hello”[2]
> 
> Result:
> Index out of range. Is: 2, should be in 0..0
>   in block  at -e line 1
> 
> Actually thrown at:
>   in block  at -e line 1
> 
> 
> 
> IRC discussion starting here:
> https://irclog.perlgeek.de/perl6/2016-10-10#i_13370830


I don't get why we throw in this case at all. We don't do it with any of the 
Positionals:

 m: say $_[42] for 1..1, (1,), [1,],  (1,).Seq
 rakudo-moar 60f898: OUTPUT: «Nil␤Nil␤(Any)␤Nil␤»

Other than Blob and Uni, which I'd say also break the consistency:

 m: say "".NFD[1]
 rakudo-moar 60f898: OUTPUT: «Index out of range. Is: 1, should be 
in 0..-1␤  in block  at  line 1␤␤Actually thrown at:␤  in block 
 at  line 1␤␤»
 m: say Blob.new[1]
 rakudo-moar 60f898: OUTPUT: «Index out of range. Is: 1, should be 
in 0..-1␤  in block  at  line 1␤␤Actually thrown at:␤  in block 
 at  line 1␤␤»

The throwage breaks the "everything is a 1-item list" idiom, as I can't safely 
do $x[1], because
it'll explode any time $x is not a non-Stringy Positional. I tried to remove 
the throwage, but it's blocked by several 6.c tests.

And regardless of that, I'm -1 on this ticket. Right now $x[1] throws 
X::OutOfRange on non-Positionals (even though it shouldn't), but the proposed 
fix for this ticket would see the possibility of yet another exception in 
another special case being thrown, all for the sake that *someone new to the 
language* *assumes* Perl 6 can index strings. IMO such special casing will be a 
hassle to more normal Perl 6 users than a helpful tip to new Perl 6 users. Just 
recall how often the Perl-5-ism exceptions get thrown when writing normal Perl 
6 code.

[perl #131270] Grabbing or picking NaN elements from a BagHash should not work (say ^5 .BagHash.pick(NaN))

[Zoffix Znet via RT]

On Mon, 08 May 2017 06:05:36 -0700, alex.jakime...@gmail.com wrote:
> Code:
> my $x = (^5).BagHash;
> say $x.grab(NaN);
> say $x
> 
> Result:
> [1 2 3 0 4]
> BagHash.new()
> 
> 
> In other words, it works like if you grabbed ∞ or *. It should
> probably error out in some way.

Thank you for the report. This is now fixed.

Fix: https://github.com/rakudo/rakudo/commit/60f898194f
Tests: https://github.com/perl6/roast/commit/b6073e1782

[perl #131270] Grabbing or picking NaN elements from a BagHash should not work (say ^5 .BagHash.pick(NaN))

[Zoffix Znet via RT]

On Mon, 08 May 2017 06:05:36 -0700, alex.jakime...@gmail.com wrote:
> Code:
> my $x = (^5).BagHash;
> say $x.grab(NaN);
> say $x
> 
> Result:
> [1 2 3 0 4]
> BagHash.new()
> 
> 
> In other words, it works like if you grabbed ∞ or *. It should
> probably error out in some way.

Thank you for the report. This is now fixed.

Fix: https://github.com/rakudo/rakudo/commit/60f898194f
Tests: https://github.com/perl6/roast/commit/b6073e1782

[perl #131270] Grabbing or picking NaN elements from a BagHash should not work (say ^5 .BagHash.pick(NaN))

[via RT]

# New Ticket Created by  Aleks-Daniel Jakimenko-Aleksejev 
# Please include the string:  [perl #131270]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131270 >


Code:
my $x = (^5).BagHash;
say $x.grab(NaN);
say $x

Result:
[1 2 3 0 4]
BagHash.new()


In other words, it works like if you grabbed ∞ or *. It should probably error 
out in some way.

[perl #131269] Doc bug in https://docs.perl6.org/language/rb-nutshell

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Thank you for your report!

However, doc bugs are reported on github. I have moved your ticket there:
https://github.com/perl6/doc/issues/1299

On 2017-05-07 20:49:39, ben-goldb...@hotmail.com wrote:
> On https://docs.perl6.org/language/rb-nutshell, it says:
>
>
> * No space allowed before the opening parenthesis of an argument
> list.
>
> foo (3, 4, 1); # Not right in Ruby or Perl 6 (in Perl 6 this would
> # try to pass a single argument of type List to foo)
> foo(3, 4, 1); # Ruby and Perl 6
> foo 3, 4, 1; # Ruby and Perl 6 - alternative parentheses-less style
>
> This doc was probably written before the GLR, because even if the ‘foo
> (’ version does produce a
> single argument of type List, then the “Single argument rule” makes it
> behave the same as the others.
>
> Another bug, further down the the file is:
>
>
> perl6 example.p6 --length=abc
> Usage:
> c.p6 [--length=] [--file=] [--verbose]
>
> Clearly that’s a copy-pasto, since the file can’t be named c.p6 and
> example.p6 both at the same time.
>