Skip Menu |
Report information
Id: 129131
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: alex.jakimenko [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [RFC] Make .. a numeric operator, please (.say for ‘42’..‘51’)
First of all, take a look at this: https://docs.perl6.org/language/traps#String_Ranges/Sequences

The question is: why do we keep this trap?

We all know that the idea of + being numeric-only has worked very well. Now, how did .. operator slip in?

I've just seen somebody stumbling upon this confusing and unexpected behavior: http://irclog.perlgeek.de/perl6/2016-08-30#i_13114494

I am not even sure if current stringy behavior is useful at all. Well, maybe it is, has anybody seen it being used in some module or something? It looks way more “WAT?” than “OK, I will probably need this in the future” to me, but I'd love to be proven wrong.

Anyway, ~.. is probably a good way to keep stringy behavior for those who need it?
Download (untitled) / with headers
text/plain 2.9k
On Mon Aug 29 19:28:10 2016, alex.jakimenko@gmail.com wrote: Show quoted text
> First of all, take a look at this: > https://docs.perl6.org/language/traps#String_Ranges/Sequences > > The question is: why do we keep this trap?
The trap doesn't have anything to do with .. being numeric-only, but with Perl 5 doing more simple range generation for strings: $ perl -wlE 'say for "♤4" .. "♥5"' Argument "�M-^Y�4" isn't numeric in foreach loop iterator at -e line 1. ♤4 $ perl6 -e '.say for "♤4" .. "♥5"' ♤4 ♤5 ♥4 ♥5 Show quoted text
> We all know that the idea of + being numeric-only has worked very > well. Now, > how did .. operator slip in?
I see little relation between .. and +. The same argument applies to … operator, should objects be coerced in it too and we add a ~… operator, for those who need it? say ["42" … "145"] [42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15] Show quoted text
> I've just seen somebody stumbling upon this confusing and unexpected > behavior: > http://irclog.perlgeek.de/perl6/2016-08-30#i_13114494
And that's why we have types! If that user used type constraints they'd spot the bug in their code much sooner. They'd have issues with calling .succ/.pred methods too. I find "one user didn't read the docs and made the wrong assumption" a poor argument for adding more operators and making a backwards in-compatible change. Show quoted text
> I am not even sure if current stringy behavior is useful at all.
So is it the stringy behaviour that's the issue or the fact that it doesn't coerce to numerics that's the issue? These aren't the only objects that the operator can take. Anything that can .succ can be used. Show quoted text
> Well, > maybe it > is, has anybody seen it being used in some module or something? It > looks way > more “WAT?” than “OK, I will probably need this in the future” to me, > but I'd > love to be proven wrong.
Off the top of my head, this is useful. I imagine such templates can be handy in more than just files: $ perl6 -e 'my $file = first !*.IO.e, "temp-000.txt" .. *; say $file' temp-000.txt $ touch temp-000.txt $ perl6 -e 'my $file = first !*.IO.e, "temp-000.txt" .. *; say $file' temp-001.txt Show quoted text
> Anyway, ~.. is probably a good way to keep stringy behavior for those > who need > it?
But what about objects other than strings? Using the `~` operator to maintain current .succ behaviour would not make sense. ------ So here's my understanding of this RFC: • .. operator must coerce its operands to Numeric. This is a backwards incompatible change. • The current behaviour is still to be maintained by adding 4 additional operators: ~.., ~^.., ~^..^, and ~..^, which would look strange for non-string objects that still want the original .succ behaviour • The related behaviour in … is to remain unchanged. My vote is -1 on this for these reasons: • Backwards-incompatible change to limit usefulness of .. • Addition of 4 extra operators that very poorly represent the behaviour they are meant to perform. • Introduced inconsistency between .. and …
I agree that this is a trap that should be fixed. That person on IRC is not the first to fall into it - I did too, and presumably also the person who wrote the "traps" page for p6doc. @Zoffix, I think you misunderstood the problem. The trap is not the .succ/.pred semantics. The trap comes from the fact that `..` and `...` with a Str endpoint *don't* use .succ/.pred: 35..* # .succ semantics 35..40 # .succ semantics "35"..* # .succ semantics "35".."40" # does something weird (and IMO useless) that is different from .succ That fourth point is the problem. Under .succ/.pred semantics, numbers and numeric strings behave equivalently. I think that's what Aleks meant with wanting the behavior to be "numeric". The operator wouldn't actually need to coerce its arguments to numbers to get that consistent behavior - it would just need to use .succ semantics in that 4th case, like it does in the other three cases. (I definitely agree with your opposition to a new ~.. operator though. The weird current behavior of the 4th case should just go away, not be promoted to its own operator.)
On 2016-08-30 11:46:53, smls75@gmail.com wrote:
Show quoted text
> I agree that this is a trap that should be fixed. That person on IRC
> is not the first to fall into it - I did too, and presumably also the
> person who wrote the "traps" page for p6doc.
>
>
> @Zoffix, I think you misunderstood the problem.
>
> The trap is not the .succ/.pred semantics.
> The trap comes from the fact that `..` and `...` with a Str endpoint
> *don't* use .succ/.pred:
>
> 35..* # .succ semantics
> 35..40 # .succ semantics
> "35"..* # .succ semantics
> "35".."40" # does something weird (and IMO useless) that is different
> from .succ
>
> That fourth point is the problem.
>
> Under .succ/.pred semantics, numbers and numeric strings behave
> equivalently.
> I think that's what Aleks meant with wanting the behavior to be
> "numeric".
> The operator wouldn't actually need to coerce its arguments to numbers
> to get that consistent behavior - it would just need to use .succ
> semantics in that 4th case, like it does in the other three cases.
>
> (I definitely agree with your opposition to a new ~.. operator though.
> The weird current behavior of the 4th case should just go away, not be
> promoted to its own operator.)


Are you sure that .succ can fix something?‘-5’.succ is ‘-6’. Does it mean that .succ is broken?

Show quoted text
> The same argument applies to … operator

Yes, you're right.


Show quoted text
> So is it the stringy behaviour that's the issue or the fact that it
> doesn't coerce to numerics that's the issue? These aren't the only
> objects that the operator can take. Anything that can .succ can be
> used.

Good questions! Well, you can always propose an alternative fix to the problem. “Don’t just do the first thing that occurs to you.” (https://perl6advent.wordpress.com/2014/12/24/day-24-seeing-wrong-right/)
Sure, you don't have to take my solution (and I'm not married to my proposals), but please acknowledge the problem.


Show quoted text
> I see little relation between .. and +

“Discourage unrelated overloading of existing operators; define new ops instead.” (https://perl6advent.wordpress.com/2014/12/24/day-24-seeing-wrong-right/)
… especially when it sneakingly does something completely different when you are not expecting it to.

I am happy that I don't have to write something like +$x + +$y (hello python) and I'm not sure why I suddenly should in case of .. operator.


Show quoted text
> And that's why we have types! If that user used type constraints
> they'd spot the bug in their code much sooner.

Um… since when we started to blame users for not using type constraints? I mean, wasn't it supposed to be optional? The language should not do stupid things if I decided not to use type constraints, and sure enough it does not do stupid things when it comes to all other operators, except .. and ...


Show quoted text
> I find "one user didn't read the docs and made the wrong assumption" a poor
> argument for adding more operators and making a backwards in-
> compatible change.

Well, the user made a completely reasonable assumption, and was expecting numeric behavior. The problem is that some Strs ended up getting into his endpoints, and the whole thing blew up. Not sure if our docs are related to that.

Speaking of the docs:

“Iterating a range (or calling the list method) uses the same semantics as the ++ prefix and postfix operators, i.e., it calls the succ method on the start point, and then the generated elements.” … and I don't see any mention of the current strings-on-both-endpoints behavior. Am I blind? I mean, I searched for 「..」 operator and it pointed me to 「Range」. What's the other way of reading the docs?

I mean, am I reading it wrong or something? It tells me that it is using .succ (yet the doc-ed trap says that it is not the case). Not that .succ is any better, it does not work with negative numbers… But what are you talking about when you say that the user didn't read the docs? I am probably missing something, but perhaps we can improve the docs for stupid people like me.


Show quoted text
> Backwards-incompatible change

We can schedule it for 9.d or whatever. I don't see why changing the behavior of something that is of questionable usefulness should be such a big NO. Let's fix the language instead.


Show quoted text
> to limit usefulness of ..

That's a good remark! Has anybody seen this stringy behavior being used somewhere in the wild? You know, maybe I'm proposing a removal of some extremely useful feature. I'd love to see some real world examples (something we should be able to have by now, I guess?).


Show quoted text
> • Addition of 4 extra operators that very poorly represent the
> behaviour they are meant to perform.

I agree with Sam. Let's just throw it away.


Show quoted text
> Introduced inconsistency between .. and …

Here you are completely right. If we are fixing 「..」, then 「...」 should be fixed as well. I didn't mention it in my first message, but please don't think that I'm saying that we should introduce inconsistencies.
RT-Send-CC: perl6-compiler [...] perl.org
On Tue Aug 30 11:46:53 2016, smls75@gmail.com wrote: Show quoted text
> The trap comes from the fact that `..` and `...` with a Str endpoint > *don't* use .succ/.pred: > > "35".."40" # does something weird (and IMO useless) that is different > from .succ
Agreed, that's weird. I'm unsure why it's counting down and is indeed "too smart" for what I'd expect it to do. On Tue Aug 30 14:06:21 2016, alex.jakimenko@gmail.com wrote: Show quoted text
> Um… since when we started to blame users for not using type > constraints? I > mean, wasn't it supposed to be optional? The language should not do > stupid > things if I decided not to use type constraints, and sure enough it > does not do > stupid things when it comes to all other operators, except .. and ...
It doesn't do "stupid things" with the .. operator either. I refrained from mentioning it earlier, but I think it would result in a more productive conversation if you did not assume the current behaviour was created by a boiled potato randomly bouncing up and down on a keyboard, calling it a "WAT" and a "stupid thing." The current behaviour is at least in part useful. If you think different behaviour is more understandable and more useful, you can justify it without demeaning the work that went into implementing the current behaviour. Types are there to catch type bugs, which is what the original user experienced by expecting a string to be operated on the same as a number contained within it. If you want to avoid types, you pay the price in uncaught type bugs. I'm not above "blaming users" for being burnt because they failed to user a language feature. Show quoted text
> I mean, am I reading it wrong or something? It tells me that it is > using .succ
I agree, the documentation can expound the templating behaviour on ranges with strings. I tried looking at speculations and they too appear to be sparse on the behaviours in strings with more than one character. Show quoted text
> We can schedule it for 9.d or whatever. I don't see why changing the > behavior > of something that is of questionable usefulness should be such a big > NO. Let's > fix the language instead.
So far, three core developers [^1][^2] think there's nothing to fix. My personal view is that it doesn't matter if it's a 9.d or a 42.d; breaking backwards compatibility should come with benefits, and I see none with this RFC. [1] http://irclog.perlgeek.de/perl6-dev/2016-08-30#i_13118518 [2] http://irclog.perlgeek.de/perl6-dev/2016-08-30#i_13118542 Show quoted text
> > to limit usefulness of ..
> > That's a good remark! Has anybody seen this stringy behavior being > used > somewhere in the wild? You know, maybe I'm proposing a removal of some > extremely useful feature. I'd love to see some real world examples > (something > we should be able to have by now, I guess?).
I already pointed out the templating behaviour to obtain non-clobbering filenames. It's useful when creating unique files based on user file uploads. The templates can also be used to evaluate if a given value fits a template. Is that not "real world" enough? Show quoted text
>
> > • Addition of 4 extra operators that very poorly represent the > > behaviour they are meant to perform.
> > I agree with Sam. Let's just throw it away.
So what would provide the .succ behaviour for objects if the RFC, as I understand it now, aims to abolish the .succ behaviour entirely. Show quoted text
>
> > Introduced inconsistency between .. and …
> > Here you are completely right. If we are fixing 「..」, then 「...」 > should be > fixed as well. I didn't mention it in my first message, but please > don't think > that I'm saying that we should introduce inconsistencies.
Fixed how? So far you mentioned the strings do "stupid things" and I see Sam mentioning that we don't want the coersion to Numeric. So what *is* the proposed behaviour? The question applies to numerics, strings, custom objects, WhateverCodes, and Subs. ---------------------------------------------------- So far I think the original RFC to make .. a numeric operator is out. There's still an issue with .. not using .succ on strings. Does anyone know why that is the case? The templating example I presented is still valid with the pure .succ behaviour.
It's hard for me to see .succ as a viable solution when negative numbers count down. I guess we should let others write their thoughts too. For example, if .succ is considered broken, then the picture is a bit more clear.

Meanwhile, another slightly interesting log: http://irclog.perlgeek.de/perl6/2016-05-16#i_12489379
To: Zoffix Znet via RT <perl6-bugs-followup [...] perl.org>
Subject: Re: [perl #129131] [RFC] Make .. a numeric operator, please (.say for ‘42’..‘51’)
CC: perl6-compiler [...] perl.org
From: "Patrick R. Michaud" <pmichaud [...] pobox.com>
Date: Tue, 30 Aug 2016 22:09:22 -0500
Download (untitled) / with headers
text/plain 631b
On Tue, Aug 30, 2016 at 07:00:43PM -0700, Zoffix Znet via RT wrote: Show quoted text
> So far I think the original RFC to make .. a numeric operator is out. > There's still an issue with .. not using .succ on strings. Does anyone > know why that is the case? The templating example I presented is still > valid with the pure .succ behaviour.
As a historical datapoint, there *was* a time when .. explicitly used .succ on strings and other non-numeric types. I know it was implemented that way in Rakudo -- I don't know why/when that behavior changed. See, for example, S03:3550 (and there are other examples sprinkled throughout S03). Pm
Download (untitled) / with headers
text/plain 2.4k
Show quoted text
> Are you sure that .succ can fix something?‘-5’.succ is ‘-6’.
Ah, I did not consider the case of negative numbers. Yeah, for those, numbers and numeric strings *don't* behave identically under .succ/.pred. Show quoted text
> Does it mean that .succ is broken?
No, I it seems to have been intended that way. See S32 <https://design.perl6.org/S32/Str.html#line_583>: The last portion of the string before the first period (which may be the entire string) is incremented, using <rangechar> to determine which characters are eligible to be incremented. And S03 <http://design.perl6.org/S03.html#line_448>: Increment of a Str (in a suitable container) works similarly to Perl 5, but is generalized slightly. A scan is made for the final alphanumeric sequence in the string that is not preceded by a '.' character. Unlike in Perl 5, this alphanumeric sequence need not be anchored to the beginning of the string, nor does it need to begin with an alphabetic character; the final sequence in the string matching <!after '.'> <rangechar>+ is incremented regardless of what comes before it. It's intended for things like: say "backup-01.txt".succ; # backup-02.txt ...and just happens to correspond to numeric increment for positive integers and decimals. On might argue if this behavior is too magical, but it was made that way intentionally, so it's not "broken". --- @Zoffix, @pmichaud: It seems, then, that there are three questions at play here: 1) Should .succ/.pred on Str be designed for convenience with filenames, or for least-surprise compatibility with numbers? 2) Should `..` and `...` (and `++` and `--`) on non-numeric types use the generic .succ/.pred, instead of coercing to Numeric? 3) Should `..` and `...` use something weirdly different from .succ/.pred in the special case that the *endpoint* is a Str? My answers would be: 1) Debatable, but it's probably best to leave it alone now. (Arguably, the filename-friendly behavior could have been put in IO::Path.succ instead of Str.succ, but oh well.) 2) I think that's fine in the case of `..` and `...`. For `--` and `++` it feels a little more fishy because those use the same symbols as the Numeric-coercing `-` and `+`, but again, probably best to accept that it is what it is, now. 3) No, kill that special case with fire... :) Since the reporter of this RT seems to be mostly concerned with (1) and (2), should I open a separate ticket for (3)?
Case in point: https://stackoverflow.com/questions/44835476


On 2016-08-29 19:28:10, alex.jakimenko@gmail.com wrote:
Show quoted text
> First of all, take a look at this:
> https://docs.perl6.org/language/traps#String_Ranges/Sequences
>
> The question is: why do we keep this trap?
>
> We all know that the idea of + being numeric-only has worked very
> well. Now,
> how did .. operator slip in?
>
> I've just seen somebody stumbling upon this confusing and unexpected
> behavior:
> http://irclog.perlgeek.de/perl6/2016-08-30#i_13114494
>
> I am not even sure if current stringy behavior is useful at all. Well,
> maybe it
> is, has anybody seen it being used in some module or something? It
> looks way
> more “WAT?” than “OK, I will probably need this in the future” to me,
> but I'd
> love to be proven wrong.
>
> Anyway, ~.. is probably a good way to keep stringy behavior for those
> who need
> it?




This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org