```[Sorry for the delay of this message. I wrote most of this mail on a
plane, but had to check a few loose ends, and forgot about that when off
the plane.]

I'm not at all convinced that we need to add ':' to '..' for ranges (or,
to say it more clearly, I'm against changing/adding it). In Ruby, ranges
use '..', and exponentiation uses '**', and so on. Other languages may
use different conventions. That's just it, there's no need to fix it.

For more details, please see below.

On 2013/10/25 2:29, David MacMahon wrote:
>
> On Oct 23, 2013, at 11:39 PM, Fuad Saud wrote:
>
>> How is a:b better than a..b? two dots are straightforward, unambiguous, well known.
>
> The tongue-in-cheek answer is that it's better because it's one character shorter. :-)  The real answer is somewhat more subtle and perhaps subjective.  Here are a few reasons.
>
> 1) The a:b form is more compact that a..b

&& is also used more than &, and is less compact, and 'and', which is
mostly used these days, is even less compact.

> and the vertical dots of the ':' character stand out better (visually) than two horizontal dots when reading code:
>
> Proposed: foo[bar.x0:bar.x1, bar.y0:bar.y1, bar.z0:bar.z1]
>
> Current:  foo[bar.x0..bar.x1, bar.y0..bar.y1, bar.z0..bar.z1]

Yes. But if we are at aesthetics and the like, the '..' is actually the
better expression of a range than ':', at least if you ask me. And you
can write the above as:

foo[bar.x0 .. bar.x1, bar.y0 .. bar.y1, bar.z0 .. bar.z1]

Or add spaces or parentheses to your liking to make it clearer and
easier to read. That's what's done all the time to make the structure of
an expression easier to grasp.

> 2) The first:last form opens up the possibility of a first:step:last syntax for Ranges that have a step size other than 1.

There are many other ways to get there. It should be fairly easy e.g. to
make first..step..last behave that way, 1..2..7 currently produces a
syntax error, but that could be changed.
(also please note that Python uses first:last:step)

> 3) It would make transliteration to Ruby of existing Matlab/OctavePython code easier.

Not really. I worked with some of my students on a project to
support/automate conversion from Python to Ruby. Some of it was easy,
some of it was tedious but straightforward, and some of it is
essentially hopeless. Converting ":" to "..", even if only in certain
circumstances, falls into the easy bucket.

The hopeless stuff includes semantic differences, in particular what
different languages take as truthy and falsy. Every
if expression:
in Python has to be rewritten as
if python_true?(expression)
in Ruby, because otherwise the program will do the wrong thing if
expression evaluates to an empty array or string or 0 or so.

> 4) It is more intuitive for new Ruby programmers who come from a Matlab/Octave/Python background.  I'm not sure how much weight this reason carries (maybe negative? :-))

Not negative, and probably even positive, but way not enough to actually
implement it. Different programming languages have (more or less)
different ways of writing operators, but there are many more important
differences that people have to get used to anyway.

> 5) Even if it's not deemed to be "better", it does provide another convenient way to make a Range. What's wrong with that?

Ranges with steps sound interesting (not personally for me but in
general), but that's a separate issue from the actual syntax, and in
particular from the :/.. discussion. I actually think we should close
the current issue and open a separate issue for ranges with steps.

Other than that, yes there are for example a lot of ways to make a
String, but each of them is there for a reason (even if in some cases it
may be only because it was adopted from Perl and not kicked out yet).

Regards,   Martin.
```