Pitch: (Almost) std libs


(Tino) #1

There have been several threads to add specific functions or types to the stdlib:
- Either in the Swift Standard Library
- Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
- Higher Kinded Types (Monads, Functors, etc.)
- Adding a new filter method which returns 2 arrays
- Add replace(_:with:) function to the stdlib
- map-like operation that returns a dictionary
- Rectangles and other common structures.
- Add zip2WithNilPadding function
- Add types BufferedSequence, BufferedGenerator
- … (guess there are some that I missed — I didn't look at last years threads at all).

Afair, none of those ideas turned into real proposals, and I think that keeping stdlib small is a good goal.

Nonetheless, there are plenty of data structures and algorithms that will be used in many places by many different teams, and each of them might write its own implementation. That's imho no big problem for algorithms, but for types, it will most likely lead to real annoyance.

I hope that we will soon have a great package manager for Swift, but I don't think that will solve this issue completely:
I wouldn't import a big third-party framework just because a tiny function like "dropWhile" could make my code more elegant...

Of course, some widely accepted libs might rise and improve interoperability, but it is hard to predict how our ecosystem will evolve, and you don't have to wait for the future to see the what could happen when there is no common base:
Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.

Instead of asking to pollute stdlib with stuff like 3d transformations, I'd prefer a set of general purpose libraries under supervision by the Swift team:
It could be a great way for "outsiders" to get into Swift development, and most likely wouldn't put to much stress and responsibility on the shoulders of each "manager".
It also could take pressure from the stdlib (and this mailinglist :slight_smile:

Beside fields of application (graphics, images, music, algebra, statistics, pattern matching, machine learning, graph theorie... whatever raises enough interest), there could also be libraries to support concepts like functional programming.

Best regards,
Tino


(David Turnbull) #2

Rust has a Nursery. C++ gets a Boost. Swift is a Breeze? The only problem
is that a lot of stdlib-like things aren't suitable for modules.

For example, it would be unfortunate if a blogger was comparing languages
and benchmarked FFT using complex numbers from a module in the breeze.
Dynamic dispatch is going to devastate the benchmarks.

Still, it's worth pursuing this. There's a lot of things which Apple
supports on Apples and won't be a priority for stdlib. The quaternions you
mentioned are a good example. Complex numbers are another because of
Accelerate.

-david https://github.com/AE9RB/SwiftGL

···

On Tue, Jan 26, 2016 at 3:32 PM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote:

There have been several threads to add specific functions or types to the
stdlib:
- Either in the Swift Standard Library
- Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
- Higher Kinded Types (Monads, Functors, etc.)
- Adding a new filter method which returns 2 arrays
- Add replace(_:with:) function to the stdlib
- map-like operation that returns a dictionary
- Rectangles and other common structures.
- Add zip2WithNilPadding function
- Add types BufferedSequence, BufferedGenerator
- … (guess there are some that I missed — I didn't look at last years
threads at all).

Afair, none of those ideas turned into real proposals, and I think that
keeping stdlib small is a good goal.

Nonetheless, there are plenty of data structures and algorithms that will
be used in many places by many different teams, and each of them might
write its own implementation. That's imho no big problem for algorithms,
but for types, it will most likely lead to real annoyance.

I hope that we will soon have a great package manager for Swift, but I
don't think that will solve this issue completely:
I wouldn't import a big third-party framework just because a tiny function
like "dropWhile" could make my code more elegant...

Of course, some widely accepted libs might rise and improve
interoperability, but it is hard to predict how our ecosystem will evolve,
and you don't have to wait for the future to see the what could happen when
there is no common base:
Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.

Instead of asking to pollute stdlib with stuff like 3d transformations,
I'd prefer a set of general purpose libraries under supervision by the
Swift team:
It could be a great way for "outsiders" to get into Swift development, and
most likely wouldn't put to much stress and responsibility on the shoulders
of each "manager".
It also could take pressure from the stdlib (and this mailinglist :slight_smile:

Beside fields of application (graphics, images, music, algebra,
statistics, pattern matching, machine learning, graph theorie... whatever
raises enough interest), there could also be libraries to support concepts
like functional programming.

Best regards,
Tino

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


(Trent Nadeau) #3

This is similar to Rust's nursery (https://github.com/rust-lang-nursery)
that contains commonly used libraries (logging, UUIDs, etc). These are
under Rust's umbrella but aren't part of the standard library and can be
versioned separately but still go through a similar stdlib process. If
libraries in the nursery become very widely used, then an RFC can come in
requesting for it to be added to the stdlib, and most libraries need to be
in the nursery before they can be added to the stdlib.

I think an approach like that would work well for Swift.

···

On Tue, Jan 26, 2016 at 6:32 PM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote:

There have been several threads to add specific functions or types to the
stdlib:
- Either in the Swift Standard Library
- Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
- Higher Kinded Types (Monads, Functors, etc.)
- Adding a new filter method which returns 2 arrays
- Add replace(_:with:) function to the stdlib
- map-like operation that returns a dictionary
- Rectangles and other common structures.
- Add zip2WithNilPadding function
- Add types BufferedSequence, BufferedGenerator
- … (guess there are some that I missed — I didn't look at last years
threads at all).

Afair, none of those ideas turned into real proposals, and I think that
keeping stdlib small is a good goal.

Nonetheless, there are plenty of data structures and algorithms that will
be used in many places by many different teams, and each of them might
write its own implementation. That's imho no big problem for algorithms,
but for types, it will most likely lead to real annoyance.

I hope that we will soon have a great package manager for Swift, but I
don't think that will solve this issue completely:
I wouldn't import a big third-party framework just because a tiny function
like "dropWhile" could make my code more elegant...

Of course, some widely accepted libs might rise and improve
interoperability, but it is hard to predict how our ecosystem will evolve,
and you don't have to wait for the future to see the what could happen when
there is no common base:
Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.

Instead of asking to pollute stdlib with stuff like 3d transformations,
I'd prefer a set of general purpose libraries under supervision by the
Swift team:
It could be a great way for "outsiders" to get into Swift development, and
most likely wouldn't put to much stress and responsibility on the shoulders
of each "manager".
It also could take pressure from the stdlib (and this mailinglist :slight_smile:

Beside fields of application (graphics, images, music, algebra,
statistics, pattern matching, machine learning, graph theorie... whatever
raises enough interest), there could also be libraries to support concepts
like functional programming.

Best regards,
Tino

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

--
Trent Nadeau


(David Turnbull) #4

Functions in a module go through dynamic dispatch. Operators are functions.
So multiplying two complex numbers won't get inlined. The stdlib uses
internal tricks so what appears as a module you import is available to be
specialized and inlined.

To see this in action, try the CubeWorld demo from here:
https://github.com/AE9RB/SwiftGL
Then change it so the math libraries aren't modules (move the files, delete
the import statements). On my system, CPU drops from 60% to 6%. It's also
the difference between 150 cubes and 1200 cubes at 60 fps. Make sure you
turn on WMO.

I'm told it won't always be this way. But it is today.

-david

···

On Tue, Jan 26, 2016 at 6:18 PM, Trent Nadeau <tanadeau@gmail.com> wrote:

I'm confused. Why would you get dynamic dispatch for a complex number just
because it's in another module? I think a complex number would always be a
struct so everything would be inline to the storage on the stack, and
there's no inheritance so no vtable.

On Tue, Jan 26, 2016 at 7:46 PM, David Turnbull via swift-evolution < > swift-evolution@swift.org> wrote:

Rust has a Nursery. C++ gets a Boost. Swift is a Breeze? The only problem
is that a lot of stdlib-like things aren't suitable for modules.

For example, it would be unfortunate if a blogger was comparing languages
and benchmarked FFT using complex numbers from a module in the breeze.
Dynamic dispatch is going to devastate the benchmarks.

Still, it's worth pursuing this. There's a lot of things which Apple
supports on Apples and won't be a priority for stdlib. The quaternions you
mentioned are a good example. Complex numbers are another because of
Accelerate.

-david https://github.com/AE9RB/SwiftGL

On Tue, Jan 26, 2016 at 3:32 PM, Tino Heth via swift-evolution < >> swift-evolution@swift.org> wrote:

There have been several threads to add specific functions or types to
the stdlib:
- Either in the Swift Standard Library
- Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
- Higher Kinded Types (Monads, Functors, etc.)
- Adding a new filter method which returns 2 arrays
- Add replace(_:with:) function to the stdlib
- map-like operation that returns a dictionary
- Rectangles and other common structures.
- Add zip2WithNilPadding function
- Add types BufferedSequence, BufferedGenerator
- … (guess there are some that I missed — I didn't look at last years
threads at all).

Afair, none of those ideas turned into real proposals, and I think that
keeping stdlib small is a good goal.

Nonetheless, there are plenty of data structures and algorithms that
will be used in many places by many different teams, and each of them might
write its own implementation. That's imho no big problem for algorithms,
but for types, it will most likely lead to real annoyance.

I hope that we will soon have a great package manager for Swift, but I
don't think that will solve this issue completely:
I wouldn't import a big third-party framework just because a tiny
function like "dropWhile" could make my code more elegant...

Of course, some widely accepted libs might rise and improve
interoperability, but it is hard to predict how our ecosystem will evolve,
and you don't have to wait for the future to see the what could happen when
there is no common base:
Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.

Instead of asking to pollute stdlib with stuff like 3d transformations,
I'd prefer a set of general purpose libraries under supervision by the
Swift team:
It could be a great way for "outsiders" to get into Swift development,
and most likely wouldn't put to much stress and responsibility on the
shoulders of each "manager".
It also could take pressure from the stdlib (and this mailinglist :slight_smile:

Beside fields of application (graphics, images, music, algebra,
statistics, pattern matching, machine learning, graph theorie... whatever
raises enough interest), there could also be libraries to support concepts
like functional programming.

Best regards,
Tino

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

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

--
Trent Nadeau


(Jordan Rose) #5

Yep. We're planning to improve this but right now it's true: inlining and generic specialization does not happen across framework boundaries.

Jordan

···

On Jan 26, 2016, at 18:49 , David Turnbull via swift-evolution <swift-evolution@swift.org> wrote:

Functions in a module go through dynamic dispatch. Operators are functions. So multiplying two complex numbers won't get inlined. The stdlib uses internal tricks so what appears as a module you import is available to be specialized and inlined.

To see this in action, try the CubeWorld demo from here: https://github.com/AE9RB/SwiftGL
Then change it so the math libraries aren't modules (move the files, delete the import statements). On my system, CPU drops from 60% to 6%. It's also the difference between 150 cubes and 1200 cubes at 60 fps. Make sure you turn on WMO.

I'm told it won't always be this way. But it is today.


(Jordan Rose) #6

Only the generics are really "dynamic dispatch", though. Non-generic code is just "function calls that aren't inlined".

Jordan

···

On Jan 26, 2016, at 19:45 , Jordan Rose <jordan_rose@apple.com> wrote:

On Jan 26, 2016, at 18:49 , David Turnbull via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Functions in a module go through dynamic dispatch. Operators are functions. So multiplying two complex numbers won't get inlined. The stdlib uses internal tricks so what appears as a module you import is available to be specialized and inlined.

To see this in action, try the CubeWorld demo from here: https://github.com/AE9RB/SwiftGL
Then change it so the math libraries aren't modules (move the files, delete the import statements). On my system, CPU drops from 60% to 6%. It's also the difference between 150 cubes and 1200 cubes at 60 fps. Make sure you turn on WMO.

I'm told it won't always be this way. But it is today.

Yep. We're planning to improve this but right now it's true: inlining and generic specialization does not happen across framework boundaries.


(Trent Nadeau) #7

I'm confused. Why would you get dynamic dispatch for a complex number just
because it's in another module? I think a complex number would always be a
struct so everything would be inline to the storage on the stack, and
there's no inheritance so no vtable.

···

On Tue, Jan 26, 2016 at 7:46 PM, David Turnbull via swift-evolution < swift-evolution@swift.org> wrote:

Rust has a Nursery. C++ gets a Boost. Swift is a Breeze? The only problem
is that a lot of stdlib-like things aren't suitable for modules.

For example, it would be unfortunate if a blogger was comparing languages
and benchmarked FFT using complex numbers from a module in the breeze.
Dynamic dispatch is going to devastate the benchmarks.

Still, it's worth pursuing this. There's a lot of things which Apple
supports on Apples and won't be a priority for stdlib. The quaternions you
mentioned are a good example. Complex numbers are another because of
Accelerate.

-david https://github.com/AE9RB/SwiftGL

On Tue, Jan 26, 2016 at 3:32 PM, Tino Heth via swift-evolution < > swift-evolution@swift.org> wrote:

There have been several threads to add specific functions or types to the
stdlib:
- Either in the Swift Standard Library
- Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
- Higher Kinded Types (Monads, Functors, etc.)
- Adding a new filter method which returns 2 arrays
- Add replace(_:with:) function to the stdlib
- map-like operation that returns a dictionary
- Rectangles and other common structures.
- Add zip2WithNilPadding function
- Add types BufferedSequence, BufferedGenerator
- … (guess there are some that I missed — I didn't look at last years
threads at all).

Afair, none of those ideas turned into real proposals, and I think that
keeping stdlib small is a good goal.

Nonetheless, there are plenty of data structures and algorithms that will
be used in many places by many different teams, and each of them might
write its own implementation. That's imho no big problem for algorithms,
but for types, it will most likely lead to real annoyance.

I hope that we will soon have a great package manager for Swift, but I
don't think that will solve this issue completely:
I wouldn't import a big third-party framework just because a tiny
function like "dropWhile" could make my code more elegant...

Of course, some widely accepted libs might rise and improve
interoperability, but it is hard to predict how our ecosystem will evolve,
and you don't have to wait for the future to see the what could happen when
there is no common base:
Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.

Instead of asking to pollute stdlib with stuff like 3d transformations,
I'd prefer a set of general purpose libraries under supervision by the
Swift team:
It could be a great way for "outsiders" to get into Swift development,
and most likely wouldn't put to much stress and responsibility on the
shoulders of each "manager".
It also could take pressure from the stdlib (and this mailinglist :slight_smile:

Beside fields of application (graphics, images, music, algebra,
statistics, pattern matching, machine learning, graph theorie... whatever
raises enough interest), there could also be libraries to support concepts
like functional programming.

Best regards,
Tino

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

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

--
Trent Nadeau


(Trent Nadeau) #8

Okay. That makes more sense. I was wondering where you would even have
dynamic dispatch to a normal function.

···

On Tue, Jan 26, 2016 at 10:46 PM, Jordan Rose <jordan_rose@apple.com> wrote:

On Jan 26, 2016, at 19:45 , Jordan Rose <jordan_rose@apple.com> wrote:

On Jan 26, 2016, at 18:49 , David Turnbull via swift-evolution < > swift-evolution@swift.org> wrote:

Functions in a module go through dynamic dispatch. Operators are
functions. So multiplying two complex numbers won't get inlined. The stdlib
uses internal tricks so what appears as a module you import is available to
be specialized and inlined.

To see this in action, try the CubeWorld demo from here:
https://github.com/AE9RB/SwiftGL
Then change it so the math libraries aren't modules (move the files,
delete the import statements). On my system, CPU drops from 60% to 6%. It's
also the difference between 150 cubes and 1200 cubes at 60 fps. Make sure
you turn on WMO.

I'm told it won't always be this way. But it is today.

Yep. We're planning to improve this but right now it's true: inlining and
generic specialization does not happen across framework boundaries.

Only the generics are really "dynamic dispatch", though. Non-generic code
is just "function calls that aren't inlined".

Jordan

--
Trent Nadeau


(Félix Cloutier) #9

Do note that any function that is dynamically linked to your program is reached through an indirect jump. This is probably what David means when he says that it uses dynamic dispatch.

Félix

···

Le 26 janv. 2016 à 22:48:49, Trent Nadeau via swift-evolution <swift-evolution@swift.org> a écrit :

Okay. That makes more sense. I was wondering where you would even have dynamic dispatch to a normal function.

On Tue, Jan 26, 2016 at 10:46 PM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

On Jan 26, 2016, at 19:45 , Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

On Jan 26, 2016, at 18:49 , David Turnbull via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Functions in a module go through dynamic dispatch. Operators are functions. So multiplying two complex numbers won't get inlined. The stdlib uses internal tricks so what appears as a module you import is available to be specialized and inlined.

To see this in action, try the CubeWorld demo from here: https://github.com/AE9RB/SwiftGL
Then change it so the math libraries aren't modules (move the files, delete the import statements). On my system, CPU drops from 60% to 6%. It's also the difference between 150 cubes and 1200 cubes at 60 fps. Make sure you turn on WMO.

I'm told it won't always be this way. But it is today.

Yep. We're planning to improve this but right now it's true: inlining and generic specialization does not happen across framework boundaries.

Only the generics are really "dynamic dispatch", though. Non-generic code is just "function calls that aren't inlined".

Jordan

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


(Craig Cruden) #10

- Higher Kinded Types (Monads, Functors, etc.)

I don’t think HKT would really work completely as a separate library since some of the functions which are implemented already in the standard library should be identified with a common protocol (i.e. Optional monad and collections monads). Which would act as a foundation for “for-comprehension” implementations (for yield) which in the end translate into map/flatMap/filter [on demand].

···

On 2016-01-27, at 6:32:45, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

There have been several threads to add specific functions or types to the stdlib:
- Either in the Swift Standard Library
- Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
- Higher Kinded Types (Monads, Functors, etc.)
- Adding a new filter method which returns 2 arrays
- Add replace(_:with:) function to the stdlib
- map-like operation that returns a dictionary
- Rectangles and other common structures.
- Add zip2WithNilPadding function
- Add types BufferedSequence, BufferedGenerator
- … (guess there are some that I missed — I didn't look at last years threads at all).

Afair, none of those ideas turned into real proposals, and I think that keeping stdlib small is a good goal.

Nonetheless, there are plenty of data structures and algorithms that will be used in many places by many different teams, and each of them might write its own implementation. That's imho no big problem for algorithms, but for types, it will most likely lead to real annoyance.

I hope that we will soon have a great package manager for Swift, but I don't think that will solve this issue completely:
I wouldn't import a big third-party framework just because a tiny function like "dropWhile" could make my code more elegant...

Of course, some widely accepted libs might rise and improve interoperability, but it is hard to predict how our ecosystem will evolve, and you don't have to wait for the future to see the what could happen when there is no common base:
Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.

Instead of asking to pollute stdlib with stuff like 3d transformations, I'd prefer a set of general purpose libraries under supervision by the Swift team:
It could be a great way for "outsiders" to get into Swift development, and most likely wouldn't put to much stress and responsibility on the shoulders of each "manager".
It also could take pressure from the stdlib (and this mailinglist :slight_smile:

Beside fields of application (graphics, images, music, algebra, statistics, pattern matching, machine learning, graph theorie... whatever raises enough interest), there could also be libraries to support concepts like functional programming.

Best regards,
Tino

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


(Howard Lovatt) #11

This is a good idea. It will be a lot easier with the module system,
particularly if that system is searchable so that you have a chance of
finding that someone has already written what you want.

···

On Wednesday, 27 January 2016, Trent Nadeau via swift-evolution < swift-evolution@swift.org> wrote:

This is similar to Rust's nursery (https://github.com/rust-lang-nursery)
that contains commonly used libraries (logging, UUIDs, etc). These are
under Rust's umbrella but aren't part of the standard library and can be
versioned separately but still go through a similar stdlib process. If
libraries in the nursery become very widely used, then an RFC can come in
requesting for it to be added to the stdlib, and most libraries need to be
in the nursery before they can be added to the stdlib.

I think an approach like that would work well for Swift.

On Tue, Jan 26, 2016 at 6:32 PM, Tino Heth via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

There have been several threads to add specific functions or types to the
stdlib:
- Either in the Swift Standard Library
- Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
- Higher Kinded Types (Monads, Functors, etc.)
- Adding a new filter method which returns 2 arrays
- Add replace(_:with:) function to the stdlib
- map-like operation that returns a dictionary
- Rectangles and other common structures.
- Add zip2WithNilPadding function
- Add types BufferedSequence, BufferedGenerator
- … (guess there are some that I missed — I didn't look at last years
threads at all).

Afair, none of those ideas turned into real proposals, and I think that
keeping stdlib small is a good goal.

Nonetheless, there are plenty of data structures and algorithms that will
be used in many places by many different teams, and each of them might
write its own implementation. That's imho no big problem for algorithms,
but for types, it will most likely lead to real annoyance.

I hope that we will soon have a great package manager for Swift, but I
don't think that will solve this issue completely:
I wouldn't import a big third-party framework just because a tiny
function like "dropWhile" could make my code more elegant...

Of course, some widely accepted libs might rise and improve
interoperability, but it is hard to predict how our ecosystem will evolve,
and you don't have to wait for the future to see the what could happen when
there is no common base:
Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.

Instead of asking to pollute stdlib with stuff like 3d transformations,
I'd prefer a set of general purpose libraries under supervision by the
Swift team:
It could be a great way for "outsiders" to get into Swift development,
and most likely wouldn't put to much stress and responsibility on the
shoulders of each "manager".
It also could take pressure from the stdlib (and this mailinglist :slight_smile:

Beside fields of application (graphics, images, music, algebra,
statistics, pattern matching, machine learning, graph theorie... whatever
raises enough interest), there could also be libraries to support concepts
like functional programming.

Best regards,
Tino

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

--
  -- Howard.


(Matthew Johnson) #12

+1. I have already suggested that we have a space for libraries that get reviewed by the community but are distributed by SPM rather than being part of stdlib and corelibs.

···

On Jan 26, 2016, at 5:48 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:

This is a good idea. It will be a lot easier with the module system, particularly if that system is searchable so that you have a chance of finding that someone has already written what you want.

On Wednesday, 27 January 2016, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is similar to Rust's nursery (https://github.com/rust-lang-nursery) that contains commonly used libraries (logging, UUIDs, etc). These are under Rust's umbrella but aren't part of the standard library and can be versioned separately but still go through a similar stdlib process. If libraries in the nursery become very widely used, then an RFC can come in requesting for it to be added to the stdlib, and most libraries need to be in the nursery before they can be added to the stdlib.

I think an approach like that would work well for Swift.

On Tue, Jan 26, 2016 at 6:32 PM, Tino Heth via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:
There have been several threads to add specific functions or types to the stdlib:
- Either in the Swift Standard Library
- Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
- Higher Kinded Types (Monads, Functors, etc.)
- Adding a new filter method which returns 2 arrays
- Add replace(_:with:) function to the stdlib
- map-like operation that returns a dictionary
- Rectangles and other common structures.
- Add zip2WithNilPadding function
- Add types BufferedSequence, BufferedGenerator
- … (guess there are some that I missed — I didn't look at last years threads at all).

Afair, none of those ideas turned into real proposals, and I think that keeping stdlib small is a good goal.

Nonetheless, there are plenty of data structures and algorithms that will be used in many places by many different teams, and each of them might write its own implementation. That's imho no big problem for algorithms, but for types, it will most likely lead to real annoyance.

I hope that we will soon have a great package manager for Swift, but I don't think that will solve this issue completely:
I wouldn't import a big third-party framework just because a tiny function like "dropWhile" could make my code more elegant...

Of course, some widely accepted libs might rise and improve interoperability, but it is hard to predict how our ecosystem will evolve, and you don't have to wait for the future to see the what could happen when there is no common base:
Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.

Instead of asking to pollute stdlib with stuff like 3d transformations, I'd prefer a set of general purpose libraries under supervision by the Swift team:
It could be a great way for "outsiders" to get into Swift development, and most likely wouldn't put to much stress and responsibility on the shoulders of each "manager".
It also could take pressure from the stdlib (and this mailinglist :slight_smile:

Beside fields of application (graphics, images, music, algebra, statistics, pattern matching, machine learning, graph theorie... whatever raises enough interest), there could also be libraries to support concepts like functional programming.

Best regards,
Tino

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

--
  -- Howard.

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


(David Turnbull) #13

I was a bit imprecise because 100% of my math libraries are generic. So
it's stuck in my head that everything gets a dynamic dispatch. But yeah,
concrete functions crossing modules are simply not-inlined. Which is still
a very big deal for simple math operations.

Regardless of the technical details, there's significant advantages to
being "stdlib" instead of "module". That's what I wanted to bring to the
discussion. It's not something you'll find in the docs but I think it's
important to know about for anyone working on this idea.

-david

···

On Tue, Jan 26, 2016 at 10:44 PM, Félix Cloutier <swift-evolution@swift.org> wrote:

This is probably what David means when he says that it uses dynamic
dispatch.


(Jordan Rose) #14

It isn't a "stdlib" vs. "module" distinction. The core standard library is compiled in an incredibly hacky mode that has pretty much broken something every time we try to extend it to something else; there are a number of bugs across the compiler that we need to fix so that we can do this reliably for arbitrary modules (without any customization). Some of the issues are listed at the bottom of the TransparentAttr.rst <https://github.com/apple/swift/blob/master/docs/TransparentAttr.rst> document, for lack of a better place to put them.

Jordan

···

On Jan 26, 2016, at 23:32 , David Turnbull via swift-evolution <swift-evolution@swift.org> wrote:

On Tue, Jan 26, 2016 at 10:44 PM, Félix Cloutier <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is probably what David means when he says that it uses dynamic dispatch.

I was a bit imprecise because 100% of my math libraries are generic. So it's stuck in my head that everything gets a dynamic dispatch. But yeah, concrete functions crossing modules are simply not-inlined. Which is still a very big deal for simple math operations.

Regardless of the technical details, there's significant advantages to being "stdlib" instead of "module". That's what I wanted to bring to the discussion. It's not something you'll find in the docs but I think it's important to know about for anyone working on this idea.


(David Turnbull) #15

I was thinking about the requirements to make this happen. It only needs
someone to do the initial organization. So I created a GitHub organization
and put up a couple projects. The Matrix4 project is feature-complete. The
Complex project is just a foothold.

Now we need more projects. The readme in the contrib project has
information about getting your project added.

https://github.com/swift-breeze

-david

···

On Tue, Jan 26, 2016 at 3:51 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

+1. I have already suggested that we have a space for libraries that get
reviewed by the community but are distributed by SPM rather than being part
of stdlib and corelibs.

On Jan 26, 2016, at 5:48 PM, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> wrote:

This is a good idea. It will be a lot easier with the module system,
particularly if that system is searchable so that you have a chance of
finding that someone has already written what you want.

On Wednesday, 27 January 2016, Trent Nadeau via swift-evolution < > swift-evolution@swift.org> wrote:

This is similar to Rust's nursery (https://github.com/rust-lang-nursery)
that contains commonly used libraries (logging, UUIDs, etc). These are
under Rust's umbrella but aren't part of the standard library and can be
versioned separately but still go through a similar stdlib process. If
libraries in the nursery become very widely used, then an RFC can come in
requesting for it to be added to the stdlib, and most libraries need to be
in the nursery before they can be added to the stdlib.

I think an approach like that would work well for Swift.

On Tue, Jan 26, 2016 at 6:32 PM, Tino Heth via swift-evolution < >> swift-evolution@swift.org> wrote:

There have been several threads to add specific functions or types to
the stdlib:
- Either in the Swift Standard Library
- Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
- Higher Kinded Types (Monads, Functors, etc.)
- Adding a new filter method which returns 2 arrays
- Add replace(_:with:) function to the stdlib
- map-like operation that returns a dictionary
- Rectangles and other common structures.
- Add zip2WithNilPadding function
- Add types BufferedSequence, BufferedGenerator
- … (guess there are some that I missed — I didn't look at last years
threads at all).

Afair, none of those ideas turned into real proposals, and I think that
keeping stdlib small is a good goal.

Nonetheless, there are plenty of data structures and algorithms that
will be used in many places by many different teams, and each of them might
write its own implementation. That's imho no big problem for algorithms,
but for types, it will most likely lead to real annoyance.

I hope that we will soon have a great package manager for Swift, but I
don't think that will solve this issue completely:
I wouldn't import a big third-party framework just because a tiny
function like "dropWhile" could make my code more elegant...

Of course, some widely accepted libs might rise and improve
interoperability, but it is hard to predict how our ecosystem will evolve,
and you don't have to wait for the future to see the what could happen when
there is no common base:
Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.

Instead of asking to pollute stdlib with stuff like 3d transformations,
I'd prefer a set of general purpose libraries under supervision by the
Swift team:
It could be a great way for "outsiders" to get into Swift development,
and most likely wouldn't put to much stress and responsibility on the
shoulders of each "manager".
It also could take pressure from the stdlib (and this mailinglist :slight_smile:

Beside fields of application (graphics, images, music, algebra,
statistics, pattern matching, machine learning, graph theorie... whatever
raises enough interest), there could also be libraries to support concepts
like functional programming.

Best regards,
Tino

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

--
Trent Nadeau

--
  -- Howard.

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

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


(Charles Kissinger) #16

I was thinking about the requirements to make this happen. It only needs someone to do the initial organization. So I created a GitHub organization and put up a couple projects. The Matrix4 project is feature-complete. The Complex project is just a foothold.

Now we need more projects. The readme in the contrib project has information about getting your project added.

In your readme, you mention random number generation as a potential project. It’s worth mentioning that Apple has a really nice set of RNG classes for Swift already, but it’s hidden away in GameplayKit. It may be a little off-topic for this list, but I would love to see that moved from GameplayKit to Foundation and become a part of cross-platform Swift.

—CK

···

On Jan 28, 2016, at 8:54 PM, David Turnbull via swift-evolution <swift-evolution@swift.org> wrote:

https://github.com/swift-breeze

-david

On Tue, Jan 26, 2016 at 3:51 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1. I have already suggested that we have a space for libraries that get reviewed by the community but are distributed by SPM rather than being part of stdlib and corelibs.

On Jan 26, 2016, at 5:48 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This is a good idea. It will be a lot easier with the module system, particularly if that system is searchable so that you have a chance of finding that someone has already written what you want.

On Wednesday, 27 January 2016, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
This is similar to Rust's nursery (https://github.com/rust-lang-nursery) that contains commonly used libraries (logging, UUIDs, etc). These are under Rust's umbrella but aren't part of the standard library and can be versioned separately but still go through a similar stdlib process. If libraries in the nursery become very widely used, then an RFC can come in requesting for it to be added to the stdlib, and most libraries need to be in the nursery before they can be added to the stdlib.

I think an approach like that would work well for Swift.

On Tue, Jan 26, 2016 at 6:32 PM, Tino Heth via swift-evolution <swift-evolution@swift.org <>> wrote:
There have been several threads to add specific functions or types to the stdlib:
- Either in the Swift Standard Library
- Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
- Higher Kinded Types (Monads, Functors, etc.)
- Adding a new filter method which returns 2 arrays
- Add replace(_:with:) function to the stdlib
- map-like operation that returns a dictionary
- Rectangles and other common structures.
- Add zip2WithNilPadding function
- Add types BufferedSequence, BufferedGenerator
- … (guess there are some that I missed — I didn't look at last years threads at all).

Afair, none of those ideas turned into real proposals, and I think that keeping stdlib small is a good goal.

Nonetheless, there are plenty of data structures and algorithms that will be used in many places by many different teams, and each of them might write its own implementation. That's imho no big problem for algorithms, but for types, it will most likely lead to real annoyance.

I hope that we will soon have a great package manager for Swift, but I don't think that will solve this issue completely:
I wouldn't import a big third-party framework just because a tiny function like "dropWhile" could make my code more elegant...

Of course, some widely accepted libs might rise and improve interoperability, but it is hard to predict how our ecosystem will evolve, and you don't have to wait for the future to see the what could happen when there is no common base:
Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.

Instead of asking to pollute stdlib with stuff like 3d transformations, I'd prefer a set of general purpose libraries under supervision by the Swift team:
It could be a great way for "outsiders" to get into Swift development, and most likely wouldn't put to much stress and responsibility on the shoulders of each "manager".
It also could take pressure from the stdlib (and this mailinglist :slight_smile:

Beside fields of application (graphics, images, music, algebra, statistics, pattern matching, machine learning, graph theorie... whatever raises enough interest), there could also be libraries to support concepts like functional programming.

Best regards,
Tino

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

--
Trent Nadeau

--
  -- Howard.

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

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

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


(Tino) #17

I was thinking about the requirements to make this happen. It only needs someone to do the initial organization. So I created a GitHub organization and put up a couple projects. The Matrix4 project is feature-complete. The Complex project is just a foothold.

Now we need more projects. The readme in the contrib project has information about getting your project added.

https://github.com/swift-breeze

I fear it won't be that simple…

First problem: "Hey github, where can I request team membership??"
I just starred the contrib repo, and I guess you can use this information to bring me into that team… but it should be more straightforward to join.
Or wait, maybe I'm to quick here: Should it be easy to join at all?

The second problem is most likely the real showstopper:
Establishing a real standard requires influence, and that is hard to earn…
It is possible someone else starts a project with the same goal next week, and maybe someone already did it last year, and I just don't know about that "standard".

Although no absolute requirement, chances for success would be significantly better if the project was managed (or at least supported) by an accepted authority — and taking into account that it is desirable that ultimately its results are shipped with Swift itself, the preferred choice for a manager is someone working in the Core Team (or, more general: At Apple).

I don't know how successful ResearchKit is right now, but I guess it could act as a prototype.

Tino


(David Turnbull) #18

The Objective-C runtime is not part of the Swift open source project. So
moving anything from GameplayKit isn't possible. You'd just be rewriting
everything in Swift.

I think the C++11 or Boost model for PRNG would be well received.

-david https://github.com/swift-breeze

···

On Thu, Jan 28, 2016 at 10:18 PM, Charles Kissinger <crk@akkyra.com> wrote:

In your readme, you mention random number generation as a potential
project. It’s worth mentioning that Apple has a really nice set of RNG
classes for Swift already, but it’s hidden away in GameplayKit. It may be a
little off-topic for this list, but I would love to see that moved from
GameplayKit to Foundation and become a part of cross-platform Swift.


(David Turnbull) #19

The org isn't private so I'm not sure what you're trying to join on GitHub
but you can contact me off-list to figure it out.

The core team is very small and super busy. You're asking them to take on
more administrative work and responsibility. If they were interested in
doing so at this time I'm sure someone would have joined the conversation.

I'm trying a different approach. Maybe it won't get very far because I'm
not influential enough. But if I can herd enough code to demonstrate the
potential of this idea, it's a lot easier to ask Apple to take on extra
work.

Ideas like this are substantially different from language changes. They can
alter the evolution of Swift but you can't put it in a typical proposal.
Think of my GitHub experiment as a proposal, not an implementation.

-david

···

On Fri, Jan 29, 2016 at 9:31 AM, Tino Heth <2th@gmx.de> wrote:

I was thinking about the requirements to make this happen. It only needs
someone to do the initial organization. So I created a GitHub organization
and put up a couple projects. The Matrix4 project is feature-complete. The
Complex project is just a foothold.

Now we need more projects. The readme in the contrib project has
information about getting your project added.

https://github.com/swift-breeze

I fear it won't be that simple…

First problem: "Hey github, where can I request team membership??"
I just starred the contrib repo, and I guess you can use this information
to bring me into that team… but it should be more straightforward to join.
Or wait, maybe I'm to quick here: Should it be easy to join at all?

The second problem is most likely the real showstopper:
Establishing a real standard requires influence, and that is hard to earn…
It is possible someone else starts a project with the same goal next week,
and maybe someone already did it last year, and I just don't know about
that "standard".

Although no absolute requirement, chances for success would be
significantly better if the project was managed (or at least supported) by
an accepted authority — and taking into account that it is desirable that
ultimately its results are shipped with Swift itself, the preferred choice
for a manager is someone working in the Core Team (or, more general: At
Apple).

I don't know how successful ResearchKit is right now, but I guess it could
act as a prototype.

Tino


(Charles Kissinger) #20

In your readme, you mention random number generation as a potential project. It’s worth mentioning that Apple has a really nice set of RNG classes for Swift already, but it’s hidden away in GameplayKit. It may be a little off-topic for this list, but I would love to see that moved from GameplayKit to Foundation and become a part of cross-platform Swift.

The Objective-C runtime is not part of the Swift open source project. So moving anything from GameplayKit isn't possible. You'd just be rewriting everything in Swift.

Understood, but rewriting the Foundation classes in Swift *is* part of the Swift open source project. I was suggesting two things: moving the classes to Foundation because they are broadly useful for much more than games; then doing the open source implementation (translation to Swift) as part of the Core Libraries subproject. But as I said above, probably off-topic for this list.

—CK

···

On Jan 29, 2016, at 12:24 AM, David Turnbull <dturnbull@gmail.com> wrote:
On Thu, Jan 28, 2016 at 10:18 PM, Charles Kissinger <crk@akkyra.com <mailto:crk@akkyra.com>> wrote:

I think the C++11 or Boost model for PRNG would be well received.

-david https://github.com/swift-breeze