Feature proposal: Range operator with step


(Milos Rankovic) #1

`Strideable` types represent an often needed generalisation of `Range` and `IntervalType`s. However, `Strideable`’s two `stride` methods are far too verbose and unbalanced (in contrast to the natural look and feel of the two interval operators). Examples like the following raise a number of issues:

    1.stride(through: 5, by: 2) // 1, 3, 5

    1.stride(through: 5, by: -2) // []

1. The method's verbosity keeps the bounds too far apart.

2. The dot syntax suggests that something is being done to the start bound, with the end bound playing the role of an argument, all of which does not really reflect the semantics of the call.

3. The direction in which we advance from one end to another of the interval is provided twice: once by the order of the bounds and then again by the sign of the stride argument.

4. Given the conceptual proximity of `Strideable`, `IntervalType` and `Range`, one would expect analogous ways of constructing them.

5. The word “stride” is not particularly friendly to programmers whose first language is not English (again in contrast to the interval operators). This is compounded by the distinction between `to` and `through` parameters.

As already noted in this thread, we could simply extend the existing types:

    extension ClosedInterval where Bound : Strideable {
        func by(stride: Bound.Stride) -> StrideThrough<Bound> {
            let (s, e) = stride < 0 ? (end, start) : (start, end)
            return s.stride(through: e, by: stride)
        }
    }

    extension HalfOpenInterval where Bound : Strideable {
        func by(stride: Bound.Stride) -> StrideTo<Bound> {
            let (s, e) = stride < 0 ? (end, start) : (start, end)
            return s.stride(to: e, by: stride)
        }
    }

So that:

    (1...5).by(2) // 1, 3, 5
    (1..<5).by(2) // 1, 3

    (1...5).by(-2) // 5, 3, 1
    (1..<5).by(-2) // 5, 3

More exotically, we could make use of subscripts:

    extension ClosedInterval where Bound : Strideable {
        subscript(stride: Bound.Stride) -> StrideThrough<Bound> {
            return by(stride)
        }
    }

    extension HalfOpenInterval where Bound : Strideable {
        subscript(stride: Bound.Stride) -> StrideTo<Bound> {
            return by(stride)
        }
    }

    (1...5)[-2] // 5, 3, 1

Or introduce a new, or overload an existing operator, with precedence just lower than the two interval operators. For example:

    func > <T> (i: ClosedInterval<T>, stride: T.Stride) -> StrideThrough<T> {
        return i.start.stride(through: i.end, by: stride)
    }

    func < <T> (i: ClosedInterval<T>, stride: T.Stride) -> StrideThrough<T> {
        return i.end.stride(through: i.start, by: -stride)
    }

    func > <T> (i: HalfOpenInterval<T>, stride: T.Stride) -> StrideTo<T> {
        return i.start.stride(to: i.end, by: stride)
    }

    func < <T> (i: HalfOpenInterval<T>, stride: T.Stride) -> StrideTo<T> {
        return i.end.stride(to: i.start, by: -stride)
    }

    for i in 1...5 < 2 {
        i // 5, 3, 1
    }

    for i in 1...5 > 2 {
        i // 1, 3, 5
    }

Not to mention a C-style `for` loop lookalike:

    for i in (1 to 5 by 2) {
        i // 1, 3, 5
    }

Obviously, this whole thread is related to the C-style `for` loop (which is more general than all of the above solutions) as well as to Haskell-style list comprehension syntax (which remains enviable). Nevertheless, I do think that a focused, lightweight feature would be the best fit for such a common need (just think, for example, how often are such sequences used for instructional purposes).

One other possibility is to introduce open-ended, infinite sequences defined by a single bound and a stride:

    // infinite sequence, starting with 5 and advancing by -2
    (5..|-2)

… which could be optionally closed by one of the interval operators:

    (5..|-2)...1

I’ve read somewhere that the “interval is going away”, in which case, a new tertiary operator may be worth considering since striding is such a fundamental operation. Or really any of the above – just not sticking to the existing `stride` methods!

milos


(Xiaodi Wu) #2

Milos, you make good points. This thread is really long and hard to
follow, so I'll reply inline below with some observations that have
been made in the past, which I think address some of them. See if you
like where things are headed.

`Strideable` types represent an often needed generalisation of `Range` and
`IntervalType`s. However, `Strideable`’s two `stride` methods are far too
verbose and unbalanced (in contrast to the natural look and feel of the two
interval operators). Examples like the following raise a number of issues:

    1.stride(through: 5, by: 2) // 1, 3, 5

    1.stride(through: 5, by: -2) // []

1. The method's verbosity keeps the bounds too far apart.

2. The dot syntax suggests that something is being done to the start bound,
with the end bound playing the role of an argument, all of which does not
really reflect the semantics of the call.

An older syntax is being restored in Swift 3: `stride(from: 1, to: 5,
by: 2)` and `stride(from: 1, through: 5, by: 2)`, and dot syntax is
being removed. Bounds are now next to each other, and the start and
end values are now visually equals.

3. The direction in which we advance from one end to another of the interval
is provided twice: once by the order of the bounds and then again by the
sign of the stride argument.

The stride direction is strictly given by the sign of the last
argument; `stride(from: 1, to: -5, by: 2)` is an empty sequence,
because you cannot get from start to end by -2. See next comment for
why I think this is a feature, not a bug.

4. Given the conceptual proximity of `Strideable`, `IntervalType` and
`Range`, one would expect analogous ways of constructing them.

5. The word “stride” is not particularly friendly to programmers whose first
language is not English (again in contrast to the interval operators). This
is compounded by the distinction between `to` and `through` parameters.

As already noted in this thread, we could simply extend the existing types:

    extension ClosedInterval where Bound : Strideable {
        func by(stride: Bound.Stride) -> StrideThrough<Bound> {
            let (s, e) = stride < 0 ? (end, start) : (start, end)
            return s.stride(through: e, by: stride)
        }
    }

    extension HalfOpenInterval where Bound : Strideable {
        func by(stride: Bound.Stride) -> StrideTo<Bound> {
            let (s, e) = stride < 0 ? (end, start) : (start, end)
            return s.stride(to: e, by: stride)
        }
    }

So that:

    (1...5).by(2) // 1, 3, 5
    (1..<5).by(2) // 1, 3

    (1...5).by(-2) // 5, 3, 1
    (1..<5).by(-2) // 5, 3

Yes, I do think that's a great idea, as do other people! Because Dave
A is making some big changes to Range (and Intervals are going away,
leaving only Range), I haven't tried to extend Range in my last
proof-of-concept, but I think there's momentum to add a
`striding(by:)` method to Range to do exactly that, `striding(by:)`
being more clear than `by(_:)`.

One difference between `Range.striding(by:)` and `stride(from:to:by:)`
will be that it's a fatal error to try to construct `1..<(-5)` as a
Range, but if you read the comments in the code for StrideTo, the
original designers of stride explicitly wanted `stride(from: 1, to:
-5, by: 1)` to be allowed. When you can't get from start to end by the
chosen stride, the result is an empty sequence instead of a fatal
error. There may be use cases where that behavior is preferred, so I'm
in favor of adding `striding(by:)` to Range but also keeping
`stride(...)`.

More exotically, we could make use of subscripts:

    extension ClosedInterval where Bound : Strideable {
        subscript(stride: Bound.Stride) -> StrideThrough<Bound> {
            return by(stride)
        }
    }

    extension HalfOpenInterval where Bound : Strideable {
        subscript(stride: Bound.Stride) -> StrideTo<Bound> {
            return by(stride)
        }
    }

    (1...5)[-2] // 5, 3, 1

Or introduce a new, or overload an existing operator, with precedence just
lower than the two interval operators. For example:

    func > <T> (i: ClosedInterval<T>, stride: T.Stride) -> StrideThrough<T>
{
        return i.start.stride(through: i.end, by: stride)
    }

    func < <T> (i: ClosedInterval<T>, stride: T.Stride) -> StrideThrough<T>
{
        return i.end.stride(through: i.start, by: -stride)
    }

    func > <T> (i: HalfOpenInterval<T>, stride: T.Stride) -> StrideTo<T> {
        return i.start.stride(to: i.end, by: stride)
    }

    func < <T> (i: HalfOpenInterval<T>, stride: T.Stride) -> StrideTo<T> {
        return i.end.stride(to: i.start, by: -stride)
    }

    for i in 1...5 < 2 {
        i // 5, 3, 1
    }

    for i in 1...5 > 2 {
        i // 1, 3, 5
    }

I've suggested something like that to be possible earlier in the
thread; didn't get too much of a positive reception. People seem to
like `by(_:)` or `striding(by:)` though.

···

On Sat, Apr 2, 2016 at 8:05 PM, Milos Rankovic via swift-evolution <swift-evolution@swift.org> wrote:

Not to mention a C-style `for` loop lookalike:

    for i in (1 to 5 by 2) {
        i // 1, 3, 5
    }

Obviously, this whole thread is related to the C-style `for` loop (which is
more general than all of the above solutions) as well as to Haskell-style
list comprehension syntax (which remains enviable). Nevertheless, I do think
that a focused, lightweight feature would be the best fit for such a common
need (just think, for example, how often are such sequences used for
instructional purposes).

One other possibility is to introduce open-ended, infinite sequences defined
by a single bound and a stride:

    // infinite sequence, starting with 5 and advancing by -2
    (5..|-2)

… which could be optionally closed by one of the interval operators:

    (5..|-2)...1

I’ve read somewhere that the “interval is going away”, in which case, a new
tertiary operator may be worth considering since striding is such a
fundamental operation. Or really any of the above – just not sticking to the
existing `stride` methods!

milos

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Milos Rankovic) #3

Thanks Xiaodi for so kindly bringing me up to speed.

This thread is really long and hard to follow

To my great embarrassment, I have only subsequent to my post realised that people kept returning to this thread and that I have as a result only seen the first burst of activity. Sincere apologies!!

See if you like where things are headed.

Yes. Especially Dave A’s brainwave that:

    Hmm, instead of defining a new protocol (Countable),
    what if we just use “Strideable where Stride : Integer”

An older syntax is being restored in Swift 3: `stride(from: 1, to: 5, by: 2)` and `stride(from: 1, through: 5, by: 2)`

This is ok. But it is also *only* ok… It does not mach the sheer sweetness of interval operators or the nil coalescing operator. It is not so Switly that such a common pattern makes me think of equivalent syntax in other languages with longing… In other words, I definitely think an operator-only syntax would be an irresistible alternative in almost every use case – if we could only come up with such operators without trespassing over existing API.

3. The direction in which we advance from one end to another of the interval is provided twice: once by the order of the bounds and then again by the sign of the stride argument.

The stride direction is strictly given by the sign of the last argument; `stride(from: 1, to: -5, by: 2)` is an empty sequence, because you cannot get from start to end by -2. See next comment for why I think this is a feature, not a bug.

Personally, I think that both semantics are valid – i.e. I’m not persuaded that the latter is necessarily more intuitive or practical. There is some merit too in starting with an interval (requiring interval.start <= interval.end), that the stride argument is of type Self.Distance not Self.Stride, so that the stride direction is explicitly opted for once at the call site – e.g. alongs the lines of (with a better choice of the operator eventually):

    for i in 1...5 > 2 {
        i // 1, 3, 5
    }

    for i in 1...5 < 2 {
        i // 5, 3, 1
    }

This would still produce empty sequences when the stride is not taking you towards the end bound, but it might be argued that it also simplifies the mental model of what is going on: “there is this interval and I want to loop through it forwards or backwards with that step size”. Omitting the second operator and the last argument would default to the unit definition for the bound type (e.g. “where Stride : Integer”), else this would emit a compile time error.

Dave A is making some big changes to Range (and Intervals are going away, leaving only Range)

and

`Range.striding(by:)` …

I like this in principle, depending on what `Range` ends up becoming… For Swift 2, I definitely prefer never touching the `Range` struct:

    extension ClosedInterval where Bound : Strideable {
        func stride(by stride: Bound.Stride) -> StrideThrough<Bound> {
            let (s, e) = stride < 0 ? (end, start) : (start, end)
            return s.stride(through: e, by: stride)
        }
    }

    extension HalfOpenInterval where Bound : Strideable {
        func stride(by stride: Bound.Stride) -> StrideTo<Bound> {
            let (s, e) = stride < 0 ? (end, start) : (start, end)
            return s.stride(to: e, by: stride)
        }
    }

    (1...5).stride(by: 2) // 1, 3, 5
    (1..<5).stride(by: 2) // 1, 3

    (1...5).stride(by: -2) // 5, 3, 1
    (1..<5).stride(by: -2) // 5, 3

Again, many thanks for your kind reply.

milos

···

On 3 Apr 2016, at 06:17, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Milos, you make good points. This thread is really long and hard to
follow, so I'll reply inline below with some observations that have
been made in the past, which I think address some of them. See if you
like where things are headed.

On Sat, Apr 2, 2016 at 8:05 PM, Milos Rankovic via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

`Strideable` types represent an often needed generalisation of `Range` and
`IntervalType`s. However, `Strideable`’s two `stride` methods are far too
verbose and unbalanced (in contrast to the natural look and feel of the two
interval operators). Examples like the following raise a number of issues:

   1.stride(through: 5, by: 2) // 1, 3, 5

   1.stride(through: 5, by: -2) // []

1. The method's verbosity keeps the bounds too far apart.

2. The dot syntax suggests that something is being done to the start bound,
with the end bound playing the role of an argument, all of which does not
really reflect the semantics of the call.

An older syntax is being restored in Swift 3: `stride(from: 1, to: 5,
by: 2)` and `stride(from: 1, through: 5, by: 2)`, and dot syntax is
being removed. Bounds are now next to each other, and the start and
end values are now visually equals.

3. The direction in which we advance from one end to another of the interval
is provided twice: once by the order of the bounds and then again by the
sign of the stride argument.

The stride direction is strictly given by the sign of the last
argument; `stride(from: 1, to: -5, by: 2)` is an empty sequence,
because you cannot get from start to end by -2. See next comment for
why I think this is a feature, not a bug.

4. Given the conceptual proximity of `Strideable`, `IntervalType` and
`Range`, one would expect analogous ways of constructing them.

5. The word “stride” is not particularly friendly to programmers whose first
language is not English (again in contrast to the interval operators). This
is compounded by the distinction between `to` and `through` parameters.

As already noted in this thread, we could simply extend the existing types:

   extension ClosedInterval where Bound : Strideable {
       func by(stride: Bound.Stride) -> StrideThrough<Bound> {
           let (s, e) = stride < 0 ? (end, start) : (start, end)
           return s.stride(through: e, by: stride)
       }
   }

   extension HalfOpenInterval where Bound : Strideable {
       func by(stride: Bound.Stride) -> StrideTo<Bound> {
           let (s, e) = stride < 0 ? (end, start) : (start, end)
           return s.stride(to: e, by: stride)
       }
   }

So that:

   (1...5).by(2) // 1, 3, 5
   (1..<5).by(2) // 1, 3

   (1...5).by(-2) // 5, 3, 1
   (1..<5).by(-2) // 5, 3

Yes, I do think that's a great idea, as do other people! Because Dave
A is making some big changes to Range (and Intervals are going away,
leaving only Range), I haven't tried to extend Range in my last
proof-of-concept, but I think there's momentum to add a
`striding(by:)` method to Range to do exactly that, `striding(by:)`
being more clear than `by(_:)`.

One difference between `Range.striding(by:)` and `stride(from:to:by:)`
will be that it's a fatal error to try to construct `1..<(-5)` as a
Range, but if you read the comments in the code for StrideTo, the
original designers of stride explicitly wanted `stride(from: 1, to:
-5, by: 1)` to be allowed. When you can't get from start to end by the
chosen stride, the result is an empty sequence instead of a fatal
error. There may be use cases where that behavior is preferred, so I'm
in favor of adding `striding(by:)` to Range but also keeping
`stride(...)`.

More exotically, we could make use of subscripts:

   extension ClosedInterval where Bound : Strideable {
       subscript(stride: Bound.Stride) -> StrideThrough<Bound> {
           return by(stride)
       }
   }

   extension HalfOpenInterval where Bound : Strideable {
       subscript(stride: Bound.Stride) -> StrideTo<Bound> {
           return by(stride)
       }
   }

   (1...5)[-2] // 5, 3, 1

Or introduce a new, or overload an existing operator, with precedence just
lower than the two interval operators. For example:

   func > <T> (i: ClosedInterval<T>, stride: T.Stride) -> StrideThrough<T>
{
       return i.start.stride(through: i.end, by: stride)
   }

   func < <T> (i: ClosedInterval<T>, stride: T.Stride) -> StrideThrough<T>
{
       return i.end.stride(through: i.start, by: -stride)
   }

   func > <T> (i: HalfOpenInterval<T>, stride: T.Stride) -> StrideTo<T> {
       return i.start.stride(to: i.end, by: stride)
   }

   func < <T> (i: HalfOpenInterval<T>, stride: T.Stride) -> StrideTo<T> {
       return i.end.stride(to: i.start, by: -stride)
   }

   for i in 1...5 < 2 {
       i // 5, 3, 1
   }

   for i in 1...5 > 2 {
       i // 1, 3, 5
   }

I've suggested something like that to be possible earlier in the
thread; didn't get too much of a positive reception. People seem to
like `by(_:)` or `striding(by:)` though.

Not to mention a C-style `for` loop lookalike:

   for i in (1 to 5 by 2) {
       i // 1, 3, 5
   }

Obviously, this whole thread is related to the C-style `for` loop (which is
more general than all of the above solutions) as well as to Haskell-style
list comprehension syntax (which remains enviable). Nevertheless, I do think
that a focused, lightweight feature would be the best fit for such a common
need (just think, for example, how often are such sequences used for
instructional purposes).

One other possibility is to introduce open-ended, infinite sequences defined
by a single bound and a stride:

   // infinite sequence, starting with 5 and advancing by -2
   (5..|-2)

… which could be optionally closed by one of the interval operators:

   (5..|-2)...1

I’ve read somewhere that the “interval is going away”, in which case, a new
tertiary operator may be worth considering since striding is such a
fundamental operation. Or really any of the above – just not sticking to the
existing `stride` methods!

milos

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution