> On Jan 6, 2016, at 11:37 AM, Jordan Rose via swift-evolution
> <[email protected]> wrote:
>
> I've bounced this idea off of Dave and Dmitri internally, so might as well
> put it out publicly:
>
> In Magic DWIM Swift, there would only be two types that you'd ever conform
> to: a destructive iteration type (today's "Generator"), and a multi-pass
> indexed type (today's "Collection"). Some operations can meaningfully use
> either one (like forEach or maxElement); these operations go on a general
> "traversable" type (today's "Sequence").
>
> In this world, both GeneratorType and CollectionType are refinements of
> SequenceType (i.e. any GeneratorType "is-a" SequenceType), including the
> necessary default implementations. Maybe we rename some of the protocols in
> the process. Again, no concrete type would ever conform to SequenceType; it's
> just something you can use as a generic constraint.
>
> We can't actually do this today because it creates a circularity between
> SequenceType and GeneratorType that the compiler can't handle. I'm pretty
> sure it's possible to change the compiler's protocol checking logic to allow
> this, though.
>
> Anyway, that's that idea. At the very least it helped me clear up my thoughts
> about Sequence, Collection, and Generator back when I was first learning them.
>
> Jordan
>
> P.S. This idea falls apart if someone comes up with a model (concrete type)
> for SequenceType that isn't a Collection or Generator. I wasn't able to think
> of one back when I was originally thinking about this, but of course that
> doesn't mean there isn't one. (Infinite collections are interesting as
> discussed on the "cycle" thread, but it's not the sequence/generator
> distinction that's really meaningful there.)
It’s not clear what you mean by a `SequenceType` that isn’t either a
`Collection` or a `Generator`, but if you mean a *concrete* sequence that:
- can be re-iterated (thus not a `Generator`)
- has no meaningful index (!) (thus not a `Collection`)
…then I can provide you with examples of such. The (!) is b/c you can of course
always use `Int` as an index, in the sense that “the value at index `n` is
obtained by iterating `n` steps from the start of the sequence”; I’ll assume
this doesn’t “count” as an index for purposes of this discussion.
Given the above, I will provide two examples.
Here is one that is stable, re-iterable, infinite, and has no “non-trivial"
index:
// Modest generalization of a seedable PRNG.
// We assume that identically-seeded sources generate
// identical elements (via `randomElement`), in identical order.
protocol RandomElementSourceType {
typealias Element
typealias Seed: Equatable
// ^ `:Equatable` isn't actually necessary, but it's nice
init(seed: Seed)
mutating func randomElement() -> Element
}
struct RandomElementGenerator<R:RandomElementSourceType> : GeneratorType {
typealias Element = R.Element
private var source: R
mutating func next() -> Element? {
return source.randomElement() // <- never stops!
}
}
struct RandomElementSequence<R:RandomElementSourceType> : SequenceType {
typealias Generator = RandomElementGenerator<R>
private let seed: R.Seed
func generate() -> Generator {
return Generator(source: R(seed: seed))
// ^ as per assumptions, each iteration will be identical b/c
// because each iteration uses the same seed
}
}
…and here is one that is not-necessarily-stable, reiteration-capable, finite
(one hopes!), and with no “non-trivial” index:
struct SuperviewGenerator : GeneratorType {
typealias Element = UIView
private var currentView: UIView? // or NSView on OS X, etc.
private init(initialView: UIView?) {
currentView = initialView
}
mutating func next() -> Element? {
guard let here = currentView else {
return nil
}
currentView = here.superview
return here
}
}
// also e.g. analogous constructs for `CALayer`,
// `UIViewController`, `UIResponder`, “folders/directories”, and so on...
struct SuperviewSequence : SequenceType {
typealias Generator = SuperviewGenerator
private let initialView: UIView?
init(initialView: UIView?) {
self.initialView = initialView
}
func generate() -> Generator {
return Generator(initialView: initialView)
}
func underestimateCount() -> Int {
return initialView != nil ? 1 : 0
}
}
// Useful extensions:
extension UIView {
// Enumerates the view hierarchy upward from `self`, including `self`.
func inclusiveSuperviewSequence() -> SuperviewSequence {
return SuperviewSequence(initialView: self)
}
// Enumerates the view hierarchy upward from `self`, omitting `self`.
func exclusiveSuperviewSequence() -> SuperviewSequence {
return SuperviewSequence(initialView: self.superview)
}
}
>
>
>> On Dec 31, 2015, at 9:52, Erica Sadun via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> I'm trying to work them out, so it's still muddled.
>>
>> Right now, I think SequenceType is better described as CollectionWalkType
>> but that's kind of (1) a mouthful and (2) not entirely accurate.
>>
>> Moving back a step: SequenceType is defined as: "A type that can be iterated
>> with a `for`...`in` loop." But it says nothing about whether that loop ever
>> terminates and many stdlib sequence functions currently don't make sense (at
>> least if they're not lazy) with respect to infinite sequences, which should
>> probably be "StreamType" not sequences. A couple of examples:
>> Here's my fib: http://swiftstub.com/189513594/
>> <http://swiftstub.com/189513594/>
>> And here's Oisin's user-input sequence:
>> https://gist.github.com/oisdk/2c7ac33bf2188528842a
>> <https://gist.github.com/oisdk/2c7ac33bf2188528842a>
>> Both of these are theoretically filterable, but they aren't dropLast-able,
>> suffix-able, properly split-able, etc.
>>
>> Hopefully that's enough of a starting point to indicate where my thinking is
>> at and what I'm trying to think through when it comes to this. -- E
>>
>>
>>> On Dec 31, 2015, at 10:09 AM, Dave Abrahams <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On Dec 31, 2015, at 9:05 AM, Erica Sadun via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> It does seem that in Swift the concepts of collection, sequence,
>>>> permutation, stream, etc are a bit muddled.
>>>
>>> This is a pretty vague critique. Do you have specifics, and suggestions
>>> that address them?
>>>
>>>>
>>>> -- E
>>>>
>>>>
>>>>> On Dec 31, 2015, at 6:51 AM, Tino Heth via swift-evolution
>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>
>>>>>> Those are collections. Collections can be iterated over multiple times.
>>>>> Speaking of the Fibonacci-numbers:
>>>>> Sure we can write an algorithm that iterates over them several times — it
>>>>> just won't ever finish the first iteration ;-)
>>>>> (only nitpicking — I just couldn't resist)
>>>>>
>>>>> Happy new year!
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> -Dave
>>>
>>
>> <open.gif> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
