LazySequenceType: make prefix return a lazy collection


(Mark Aron Szulyovszky) #1

Hi,

I came across hit issue while chaining filter() and prefix() on lazy
sequences:
https://bugs.swift.org/browse/SR-461

And started wondering if it would be more consistent if
lazy.filter().prefix() returned a custom
LazySequenceType<Generator.Element> instead of
Slice<LazyFilterCollection<Range<Generator.Element>>>.

That way lazy.filter().prefix() could be used to chain *pure lazy
operations*, which can be actually quite useful in some cases.

I understand that this has implications, and it would make prefix() less
consistent in terms of return type, but it would eliminate confusion like
SR-461 <https://bugs.swift.org/browse/SR-461>.
Also, this wouldn't be a much different than how how lazy.filter() is
implemented, since it also returns a custom LazySequenceType instead of
SequenceType.

Has this been considered before? Would there be any cases where this would
create unintended side effects?
As far as I see, it wouldn't change the meaning of prefix(), only would it
extend its usefulness.

I submitted a PR to the SwiftSequence library that demonstrates the
implementation of this:
https://github.com/itchingpixels/SwiftSequence/commit/26101e5aec6c266048bbad4db7b44b9c453f07ca

And I'm happy to contribute to contribute it to stdlib if people find it
useful.

Thanks a lot!

Mark


(Tony Parker) #2

Hi Mark,

I’m going to loop in the swift-dev list for this question.

- Tony

···

On Jan 4, 2016, at 5:15 AM, Mark Aron Szulyovszky via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi,

I came across hit issue while chaining filter() and prefix() on lazy sequences:
https://bugs.swift.org/browse/SR-461

And started wondering if it would be more consistent if lazy.filter().prefix() returned a custom LazySequenceType<Generator.Element> instead of Slice<LazyFilterCollection<Range<Generator.Element>>>.

That way lazy.filter().prefix() could be used to chain pure lazy operations, which can be actually quite useful in some cases.

I understand that this has implications, and it would make prefix() less consistent in terms of return type, but it would eliminate confusion like SR-461 <https://bugs.swift.org/browse/SR-461>.
Also, this wouldn't be a much different than how how lazy.filter() is implemented, since it also returns a custom LazySequenceType instead of SequenceType.

Has this been considered before? Would there be any cases where this would create unintended side effects?
As far as I see, it wouldn't change the meaning of prefix(), only would it extend its usefulness.

I submitted a PR to the SwiftSequence library that demonstrates the implementation of this: https://github.com/itchingpixels/SwiftSequence/commit/26101e5aec6c266048bbad4db7b44b9c453f07ca

And I'm happy to contribute to contribute it to stdlib if people find it useful.

Thanks a lot!

Mark
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Dmitri Gribenko) #3

Hi Mark,

I’m going to loop in the swift-dev list for this question.

Thanks, Tony!

Hi,

I came across hit issue while chaining filter() and prefix() on lazy
sequences:
https://bugs.swift.org/browse/SR-461

And started wondering if it would be more consistent if
lazy.filter().prefix() returned a custom
LazySequenceType<Generator.Element> instead of
Slice<LazyFilterCollection<Range<Generator.Element>>>.

That way lazy.filter().prefix() could be used to chain *pure lazy
operations*, which can be actually quite useful in some cases.

Hi Mark,

I think this would make a lot of sense, since the lazy implementation of
prefix() would allow the operation to be performed in O(1) instead of
triggering the whole calculation chain. But for random-access collections,
keeping the current implementation would be best, I think. Would you mind
sending a quick summary of the proposed new API to swift-evolution? That
mailing list is the preferred place for such discussions. You can read
more about it here:
https://github.com/apple/swift-evolution/blob/master/process.md

The ambiguity issue that you are seeing, I think, should be viewed as a
type checker issue and should be solved separately.

Dmitri

···

On Mon, Jan 4, 2016 at 2:21 PM, Tony Parker via swift-dev < swift-dev@swift.org> wrote:

On Jan 4, 2016, at 5:15 AM, Mark Aron Szulyovszky via swift-corelibs-dev < > swift-corelibs-dev@swift.org> wrote:

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/