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

Make .. a numeric operator, please (.say for ‘42’..‘51’) #5626

Open
p6rt opened this issue Aug 30, 2016 · 11 comments
Open

Make .. a numeric operator, please (.say for ‘42’..‘51’) #5626

p6rt opened this issue Aug 30, 2016 · 11 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented Aug 30, 2016

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

Searchable as RT129131$

@p6rt
Copy link
Author

p6rt commented Aug 30, 2016

From @AlexDaniel

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?

@p6rt
Copy link
Author

p6rt commented Aug 30, 2016

From @zoffixznet

On Mon Aug 29 19​:28​:10 2016, alex.jakimenko@​gmail.com wrote​:

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

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]

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.

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.

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

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 �

@p6rt
Copy link
Author

p6rt commented Aug 30, 2016

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

@p6rt
Copy link
Author

p6rt commented Aug 30, 2016

From @smls

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.)

@p6rt
Copy link
Author

p6rt commented Aug 30, 2016

From @AlexDaniel

On 2016-08-30 11​:46​:53, smls75@​gmail.com wrote​:

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?

@p6rt
Copy link
Author

p6rt commented Aug 30, 2016

From @AlexDaniel

The same argument applies to … operator

Yes, you're right.

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.

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.

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

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.

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.

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?).

• 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.

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.

@p6rt
Copy link
Author

p6rt commented Aug 31, 2016

From @zoffixznet

On Tue Aug 30 11​:46​:53 2016, smls75@​gmail.com wrote​:

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​:

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.

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.

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

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?

� 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.

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.

@p6rt
Copy link
Author

p6rt commented Aug 31, 2016

From @AlexDaniel

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

@p6rt
Copy link
Author

p6rt commented Aug 31, 2016

From @pmichaud

On Tue, Aug 30, 2016 at 07​:00​:43PM -0700, Zoffix Znet via RT wrote​:

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

@p6rt
Copy link
Author

p6rt commented Aug 31, 2016

From @smls

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.

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>&#8203;:

  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)?

@p6rt
Copy link
Author

p6rt commented Jul 3, 2017

From @AlexDaniel

Case in point​: https://stackoverflow.com/questions/44835476

On 2016-08-29 19​:28​:10, alex.jakimenko@​gmail.com wrote​:

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?

@p6rt p6rt added the RFC Request For Comments label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

1 participant