LazySequenceType: make prefix return a lazy collection

Mark_Aron_Szulyovszk · 2016-01-04T13:15:52.000Z

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 · 2016-01-04T22:21:04.000Z

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:
[SR-461] prefix() chained after filter() confuses type inference when used on a sequence that uses AnyGenerator · Issue #43078 · apple/swift · GitHub

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: added lazyPrefix · almostintuitive/SwiftSequence@26101e5 · GitHub

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

gribozavr · 2016-02-14T05:52:40.000Z

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:
[SR-461] prefix() chained after filter() confuses type inference when used on a sequence that uses AnyGenerator · Issue #43078 · apple/swift · GitHub

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:

github.com

apple/swift-evolution/blob/main/process.md

# Swift Evolution Process

Swift is a powerful and intuitive programming language that is designed to make writing and maintaining correct programs easier. Swift is growing and evolving, guided by a community-driven process referred to as the Swift evolution process, maintained by the [Language Steering Group][language-steering-group]. This document outlines the Swift evolution process and how a feature grows from a rough idea into something that can improve the Swift development experience for millions of programmers.

## Scope

The Swift evolution process covers all design changes, no matter how small, to the Swift language, its standard library, and the core tools necessary to build Swift programs.  This includes additions, removals, and changes to:
- the features of the Swift language,
- the public interface of the Swift standard library,
- the configuration of the Swift compiler, and
- the core tools of the Swift package ecosystem, including the configuration of the [Swift package manager](https://www.swift.org/package-manager/) and the design of its manifest files.

The design of other tools, such as IDEs, debuggers, and documentation generators, is not covered by the evolution process.  The Core Team may create workgroups to guide and make recommendations about the development of these tools, but the output of those workgroups is not reviewed.

The evolution process does not cover experimental features, which can be added, changed, or removed at any time.  Implementors should take steps to prevent the accidental use of experimental features, such as by enabling them only under explicitly experimental options.  Features should not be allowed to remain perpetually experimental; a feature with no clear path for development into an official feature should be removed.

Changes such as bug fixes, optimizations, or diagnostic improvements can be contributed via the normal contribution process; see [Contributing to Swift](https://www.swift.org/contributing/).  Some bug fixes are effectively substantial changes to the design, even if they're just making the implementation match the official documentation; whether such a change requires evolution review is up to the appropriate evolution workgroup.

Which parts of the Swift project are covered by the evolution process is ultimately up to the judgment of the Core Team.

This file has been truncated. show original

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>*/