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
Make .. a numeric operator, please (.say for ‘42’..‘51’) #5626
Comments
From @AlexDanielFirst 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? |
From @zoffixznetOn Mon Aug 29 19:28:10 2016, alex.jakimenko@gmail.com wrote:
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"' $ perl6 -e '.say for "�4" .. "�5"'
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"]
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.
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.
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'
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: My vote is -1 on this for these reasons: |
The RT System itself - Status changed from 'new' to 'open' |
From @smlsI 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. 35..* # .succ semantics That fourth point is the problem. Under .succ/.pred semantics, numbers and numeric strings behave equivalently. (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.) |
From @AlexDanielOn 2016-08-30 11:46:53, smls75@gmail.com wrote:
Are you sure that .succ can fix something?‘-5’.succ is ‘-6’. Does it mean that .succ is broken? |
From @AlexDaniel
Yes, you're right.
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/)
“Discourage unrelated overloading of existing operators; define new ops instead.” (https://perl6advent.wordpress.com/2014/12/24/day-24-seeing-wrong-right/) 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.
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 ...
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.
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.
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 agree with Sam. Let's just throw it away.
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. |
From @zoffixznetOn Tue Aug 30 11:46:53 2016, smls75@gmail.com wrote:
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:
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.
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.
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
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?
So what would provide the .succ behaviour for objects if the RFC, as I understand it now, aims to abolish the .succ behaviour entirely.
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. |
From @AlexDanielIt'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 |
From @pmichaudOn Tue, Aug 30, 2016 at 07:00:43PM -0700, Zoffix Znet via RT wrote:
As a historical datapoint, there *was* a time when .. explicitly used Pm |
From @smls
Ah, I did not consider the case of negative numbers. Yeah, for those, numbers and numeric strings *don't* behave identically under .succ/.pred.
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 And S03 <http://design.perl6.org/S03.html#line_448>​: Increment of a Str (in a suitable container) works similarly to 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? 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)? |
From @AlexDanielCase in point: https://stackoverflow.com/questions/44835476 On 2016-08-29 19:28:10, alex.jakimenko@gmail.com wrote:
|
Migrated from rt.perl.org#129131 (status was 'open')
Searchable as RT129131$
The text was updated successfully, but these errors were encountered: