the closed range operator

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

the closed range operator

Josh Brown
After the half-closed range operator change in Beta 3 (which I'm happy with), I started thinking about the closed range operator. Since they're both three characters now, it seems like it might make sense to use the equals sign at the end of the closed range operator instead of a dot. So instead of the following:

for index in 1...5 {
    println("\(index) times 5 is \(index * 5)")
}

It would be:



I talked to a friend about this who thought it was a good idea and said I should file a radar. I

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/6eceb0f9-0d9c-4fc1-b7ec-05706b4e049d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Josh Brown
Oops - sorry, accidentally hit the wrong combination of keys and posted too early.

Would this make sense instead?

for index in 1..=5 {
    println("\(index) times 5 is \(index * 5)")
}

Before I go to radar, I thought I'd ask and hear others' opinions. With this approach, range operators would be more symmetrical/balanced (I'm not sure what the word is) - ..< and ..=What do you think?

Josh


On Monday, July 28, 2014 8:46:40 AM UTC-4, Josh Brown wrote:
After the half-closed range operator change in Beta 3 (which I'm happy with), I started thinking about the closed range operator. Since they're both three characters now, it seems like it might make sense to use the equals sign at the end of the closed range operator instead of a dot. So instead of the following:

for index in 1...5 {
    println("\(index) times 5 is \(index * 5)")
}

It would be:



I talked to a friend about this who thought it was a good idea and said I should file a radar. I

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/6ae09041-8df5-4d2b-a67e-d4cf0338c7dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Jens Alfke

On Jul 28, 2014, at 5:50 AM, Josh Brown <[hidden email]> wrote:

Before I go to radar, I thought I'd ask and hear others' opinions. With this approach, range operators would be more symmetrical/balanced (I'm not sure what the word is) - ..< and ..=What do you think?

Ugh, no. At least one of them should remain simple and clean. The “=“ sign in there would make this easily confusable with assignment during quick skimming.

—Jens

smime.p7s (6K) Download Attachment
Tom
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Tom
In reply to this post by Josh Brown


On Monday, July 28, 2014 2:50:55 PM UTC+2, Josh Brown wrote:
Oops - sorry, accidentally hit the wrong combination of keys and posted too early.

Would this make sense instead?

for index in 1..=5 {
    println("\(index) times 5 is \(index * 5)")
}

Before I go to radar, I thought I'd ask and hear others' opinions. With this approach, range operators would be more symmetrical/balanced (I'm not sure what the word is) - ..< and ..=What do you think?
 
I think it's ok the way it is now. Try to see it like this:

The closed range (2...5) is symmetric, as it includes the first value and the last value: 2, 3, 4, 5. This is reflected by a perfectly symmetric operator "...".

The half-closed (half-open?) range (2..<5) is asymmetric, it includes the first value but not the last value: 2, 3, 4, !5. The asymmetry is consistently reflected by an asymmetrical operator "..<".

If you really would use the "=" sign in the closed range operator you had to write "=.=". Not very nice ;-) 

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/267e671c-97ac-4ec7-9ec3-4abc9579c7fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Josh Brown
That's a great point - I hadn't thought of it that way. Thanks for taking the time to explain your thoughts!

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/354ccb06-95b5-477b-9d49-ae78d8aa0290%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Andy Lee
In reply to this post by Tom
On Jul 29, 2014, at 8:35 AM, Tom <[hidden email]> wrote:

> On Monday, July 28, 2014 2:50:55 PM UTC+2, Josh Brown wrote:
> Oops - sorry, accidentally hit the wrong combination of keys and posted too early.
>
> Would this make sense instead?
>
> for index in 1..=5 {
>     println("\(index) times 5 is \(index * 5)")
> }
>
> Before I go to radar, I thought I'd ask and hear others' opinions. With this approach, range operators would be more symmetrical/balanced (I'm not sure what the word is) - ..< and ..=. What do you think?
>  
> I think it's ok the way it is now.

I could live with it too, the way it is now, though it is not my preference.

There were at least two common complaints about the original operators: (1) they were too easy to confuse with each other, and (2) they would irk programmers who use Ruby, which uses the operators in the opposite way.  Both complaints were not merely matters of taste; they were concerns about it being easy to make mistakes.

The current operators take care of (1).  Josh's proposal (which I also suggested a while back and would prefer) would take care of (2).

> Try to see it like this:
>
> The closed range (2...5) is symmetric, as it includes the first value and the last value: 2, 3, 4, 5. This is reflected by a perfectly symmetric operator "...".
>
> The half-closed (half-open?) range (2..<5) is asymmetric, it includes the first value but not the last value: 2, 3, 4, !5. The asymmetry is consistently reflected by an asymmetrical operator "..<".
>
> If you really would use the "=" sign in the closed range operator you had to write "=.=". Not very nice ;-)

That's only if you assume that palindromicity of the operator is the only way to look at it.  It happens to work for the current operators, but other possibilities also have reasonable mnemonics.

[The current way] x..<y and x...y
[Mnemonic] "..<" is asymmetric (and its meaning is clear), and "..." is symmetric (and easy to type).  A drawback is that Ruby programmers might inadvertently type "..." to mean half-closed because that's still in their muscle memory from Ruby work they were doing ten minutes ago.

[Original Swift] x..y and x...y
[Mnemonic] As offered by Chris Lattner himself: "..." has one more character, indicating a range with one more element.

[Ruby style] x...y and x..y
[Mnemonic] The .. operator means closed range everywhere else, no mnemonic needed for that; in "...", the third dot "pushes" the last element out of the range.
[Alternate mnemonic] Three dots is an ellipsis, which means something is omitted.

[Josh's/my proposal] x..<y and x..=y
[Mnemonic] The operators have a parallel structure (partly why this version appeals to me): ".." means this is a range operator, "<" means the last element of the range is less than y, and "=" means it equals y.

[Yet another possibility] x..<y and x..y
[Mnemonic] ".." means closed range everywhere else.  The "<" means the last element of the range is less than y.  A drawback of this is that you could forget to type "<" when you should have.

--Andy

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/5937FFDC-4F51-4A3C-82ED-EC57C88D7470%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Jeremy Pereira

On 31 Jul 2014, at 03:00, Andy Lee <[hidden email]> wrote:

>
> [The current way] x..<y and x...y
> [Mnemonic] "..<" is asymmetric (and its meaning is clear), and "..." is symmetric (and easy to type).  A drawback is that Ruby programmers might inadvertently type "..." to mean half-closed because that's still in their muscle memory from Ruby work they were doing ten minutes ago.

Due respect to Ruby programmers, but why do we care if they have the operators the "wrong way around"[1]?  Swift doesn't even take much notice of the muscle memory of Objective-C programmers.  The number of times I've written

     a = foo.doSomething: bar;

instead of

     a = foo.doSomething(bar);

is at least several.  


[1] Obviously, the right way around is somewhat subjective, but the idea that one more dot means one more value seems logical to me.

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/E1B5699B-94C6-41C7-86A8-4ABE0CDE88E1%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.
Tom
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Tom
In reply to this post by Josh Brown
@Andy Lee, Thanks for the nice comparison.

That's only if you assume that palindromicity of the operator is the only way to look at it

Of course, nobody is forced to view it under the symmetry/asymmetry aspect.

[Mnemonic] As offered by Chris Lattner himself: "..." has one more character, indicating a range with one more element. 

Yes, this is a very good point too.

Not sure if I prefer the elegant original (pure-dot) notation or the more explicit new one. (But I prefer any of them over a "=" notation.)


To make it more visual:


The original notation:

Closed range "...":

|  starting value  | inbetween values |   final value    |
|         .        |         .        |         .        |

Half-open range "..":

|  starting value  | inbetween values |         –        |
|         .        |         .        |   [null marker]  |

The final value (element) is missing and this is represented by a missing final dot (missing index for the missing element). So, that notation is consistent A) regarding symmetry/asymmetry as well as B) regarding the representation of elements. But, unfortunately, if we look at an isolated ".." operator the asymmetry is lost, because it appears to be symmetric.


The new notation:

Closed range "...":

|  starting value  | inbetween values |   final value    |
|         .        |         .        |         .        |

Half-open range "..<":

|  starting value  | inbetween values |         –        |
|         .        |         .        |         <        |

Basically the same as with the old operators: The final value (element) is missing and this is represented by a missing final dot (missing index for the missing element). But now the null marker is replaced by a more explicit symbol "<". We could also say the "<" makes the null marker visible, or: the fact that the element is missing becomes apparent.

So this notation – just like the old one – is consistent A) regarding symmetry/asymmetry as well as B) regarding the representation of elements. But this time not only the missing element but also the asymmetry remains visible, even when we look at an isolated "..<" operator.


The "=" notation:

Closed range "..=":

|  starting value  | inbetween values |   final value    |
|         .        |         .        |         =        |

Half-open range "..<":

|  starting value  | inbetween values |         –        |
|         .        |         .        |         <        |

With this notation we double-lose consistency: in the symmetry/asymmetry department as well as in the elements department. Why should the final element be represented by another symbol as the other two if all of them are equally included?

The only advantage I see is that a confusion with ruby is less likely. But, honestly, I think from the moment on when you have learned the half-open "..<" you won't have a second of doubt about the meaning of the "...".

And at latest after having read this thread you won't ever forget it ;-)



--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/74b8bdb9-dab3-4912-956c-b0d79b21b93f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Andy Lee
In reply to this post by Jeremy Pereira
On Aug 4, 2014, at 5:14 AM, Jeremy Pereira <[hidden email]> wrote:
> On 31 Jul 2014, at 03:00, Andy Lee <[hidden email]> wrote:
>
>> [The current way] x..<y and x...y
>> [Mnemonic] "..<" is asymmetric (and its meaning is clear), and "..." is symmetric (and easy to type).  A drawback is that Ruby programmers might inadvertently type "..." to mean half-closed because that's still in their muscle memory from Ruby work they were doing ten minutes ago.
>
> Due respect to Ruby programmers, but why do we care if they have the operators the "wrong way around"[1]?  Swift doesn't even take much notice of the muscle memory of Objective-C programmers.

To frame it as us vs. them -- "Who cares how *they* feel?  They sure don't care about us!" -- is to miss the point.  The point is to minimize errors on our platform, for all comers.  The tricky part is the tradeoffs in doing so.

--Andy

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/9038ED9C-790C-44A5-8ADE-3D6440CF510A%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Jeremy Pereira

On 4 Aug 2014, at 14:27, Andy Lee <[hidden email]> wrote:

>>
>> Due respect to Ruby programmers, but why do we care if they have the operators the "wrong way around"[1]?  Swift doesn't even take much notice of the muscle memory of Objective-C programmers.
>
> To frame it as us vs. them -- "Who cares how *they* feel?  They sure don't care about us!" -- is to miss the point.  The point is to minimize errors on our platform, for all comers.  The tricky part is the tradeoffs in doing so.
>
> --Andy
>

This is not about "us versus them" but about recognising that different languages do the same things in different ways.  If there was some global standard syntax for ranges and it happened to coincide with the one used by Ruby, fine.  However, by adopting Ruby's standard, maybe you are making it more difficult for some other group of programmers.  

The objective should not be to ape some particular existing language (unless its ideas are good) but to come up with a clear easily understood syntax for _Swift_ programmers.  

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/5C52929A-B065-4575-8247-626D50069A7D%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Andy Lee
On Aug 4, 2014, at 9:33 AM, Jeremy Pereira <[hidden email]> wrote:
> The objective should not be to ape some particular existing language (unless its ideas are good) but to come up with a clear easily understood syntax for _Swift_ programmers.

Nobody's talking about aping.  In fact, the Ruby way is one of the few options I haven't seen an argument for.  (I can imagine one; I just haven't seen it, certainly not on this thread.)

--Andy

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/A77E4EF4-0CC8-4E58-B139-C942CE9CDF77%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: the closed range operator

Andy Lee
In reply to this post by Tom
On Aug 4, 2014, at 8:20 AM, Tom <[hidden email]> wrote:

@Andy Lee, Thanks for the nice comparison.

That's only if you assume that palindromicity of the operator is the only way to look at it

Of course, nobody is forced to view it under the symmetry/asymmetry aspect.

Just to be clear: I think the symmetry aspect is a neat way of seeing the current operators, and as I said I can accept them as they are.  My point was less to criticize them (and definitely not to criticize your model) and more to point out there are ways to remember other possibilities too, including the **opposites** ".."/"..." and "..."/"..".  The existence of a mnemonic for one way of doing it does not automatically make that way better.


[Mnemonic] As offered by Chris Lattner himself: "..." has one more character, indicating a range with one more element. 

Yes, this is a very good point too.

Not sure if I prefer the elegant original (pure-dot) notation or the more explicit new one.

I would have to put the original notation way at the bottom of the possibilities we've discussed.  Set aside that it's practically hostile to Ruby developers.  Set aside the worries about 2 dots looking too similar to 3 dots (it's been a long time since I made a = vs. == mistake... though come to think of it, how could I possibly know that for sure!).  I think it was a mistake to have ".." mean half-closed when it has long meant closed everywhere else I'm aware of, not just in Ruby.  For that alone I'm happy about the change.

(But I prefer any of them over a "=" notation.)

At a certain point the discussion crosses into the realm of personal preferences, where different options appeal to how different people are wired.  One person's "elegant" is another person's "hideous" -- consider the spectrum of reactions that newcomers have had to Objective-C's messaging syntax.

I like the "=" because I see it as a qualifier for the ".." part of the operator that parallels the "<" in "..<".  Also it reminds me of what for-loops look like when I include the last value -- that's a strong visual cue for me.  You dislike the "=" because you see the operator as a whole -- all three characters combined -- as a sort of ideogram for the operation, so the "..." makes more sense to you.  At this point it's just Big-Endian vs. Little-Endian all over again.



To make it more visual:


The original notation:

Closed range "...":

|  starting value  | inbetween values |   final value    |
|         .        |         .        |         .        |

Half-open range "..":

|  starting value  | inbetween values |         –        |
|         .        |         .        |   [null marker]  |

The final value (element) is missing and this is represented by a missing final dot (missing index for the missing element). So, that notation is consistent A) regarding symmetry/asymmetry as well as B) regarding the representation of elements. But, unfortunately, if we look at an isolated ".." operator the asymmetry is lost, because it appears to be symmetric.


The new notation:

Closed range "...":

|  starting value  | inbetween values |   final value    |
|         .        |         .        |         .        |

Half-open range "..<":

|  starting value  | inbetween values |         –        |
|         .        |         .        |         <        |

Basically the same as with the old operators: The final value (element) is missing and this is represented by a missing final dot (missing index for the missing element). But now the null marker is replaced by a more explicit symbol "<". We could also say the "<" makes the null marker visible, or: the fact that the element is missing becomes apparent.

So this notation – just like the old one – is consistent A) regarding symmetry/asymmetry as well as B) regarding the representation of elements. But this time not only the missing element but also the asymmetry remains visible, even when we look at an isolated "..<" operator.


The "=" notation:

Closed range "..=":

|  starting value  | inbetween values |   final value    |
|         .        |         .        |         =        |

Half-open range "..<":

|  starting value  | inbetween values |         –        |
|         .        |         .        |         <        |

With this notation we double-lose consistency: in the symmetry/asymmetry department as well as in the elements department. Why should the final element be represented by another symbol as the other two if all of them are equally included?

Again, it depends on how you interpret the symbols.  My way is consistent in that the last character of each range operator is a comparison operator.  Your way is consistent in that the visual symmetry of each range operator corresponds to its mathematical symmetry.


The only advantage I see is that a confusion with ruby is less likely.

In practice, with the current operators (heck, even with the originals) Ruby-confusion might be a very minor edge case at worst, a non-issue at best.  I don't know enough to say.  I do know that if I were writing a book on Swift today I'd add a (small) side note that "..." has a different meaning in the two languages.  I would consider it worth mentioning.

But, honestly, I think from the moment on when you have learned the half-open "..<" you won't have a second of doubt about the meaning of the "...".

Sure, it will help a lot to know that those are the two operators and both have three characters.  If you stop and think, you can't go wrong, and hopefully it will become habitually ingrained.

And at latest after having read this thread you won't ever forget it ;-)

:) :)

--Andy

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/1CEFCA2A-36DF-4BC8-BB6B-040B892A1A99%40earthlink.net.
For more options, visit https://groups.google.com/d/optout.