higher kinded types vs Python's syntactic sugars


(Amir Michail) #1

How is it possible that higher kinded types are being discussed seriously while Python’s syntactic sugars (e.g., comprehensions) have been dismissed as too confusing?


(Austin Zheng) #2

Different people are participating in different topics, so I wouldn't take
the different responses as indicative of the community's opinion as a whole.

Another thing: higher-kinded types would make it easier to implement the
sort of list comprehensions that languages like Scala have. The philosophy
of the language, as stated by multiple members of the core team, is to
prefer building tools that allow language features to be defined in
libraries, over hard-coding specific features into the language grammar and
specification. Here are a couple of examples:

- Custom operators and operator overloading, so things like '+' can be
defined in the standard library
- isUniquelyReferenced(), so that library developers can implement their
own collections with value semantics
- Literal convertible protocols, so that third-party types can be
initialized from literals in source code when it makes sense

Best,
Austin

···

On Thu, Dec 17, 2015 at 3:29 PM, Amir Michail via swift-evolution < swift-evolution@swift.org> wrote:

How is it possible that higher kinded types are being discussed seriously
while Python’s syntactic sugars (e.g., comprehensions) have been dismissed
as too confusing?

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


(Joe Groff) #3

Posting stuff like this isn't cool. Different people have different interests in different topics, and discussion isn't zero-sum; talking about topics you don't care about isn't exclusive to talking about ones you do.

-Joe

···

On Dec 17, 2015, at 3:29 PM, Amir Michail via swift-evolution <swift-evolution@swift.org> wrote:

How is it possible that higher kinded types are being discussed seriously while Python’s syntactic sugars (e.g., comprehensions) have been dismissed as too confusing?


(Félix Cloutier) #4

Everybody understands what list comprehensions are about, what are the current options, and what the proposal adds. Not a lot of people understand higher kinded types, what are the current options, and what the proposal adds.

People are saying that the current equivalents for list comprehensions are good enough. HKT people are saying that there are things that are simply impossible in Swift right now.

···

Le 17 déc. 2015 à 18:29:14, Amir Michail via swift-evolution <swift-evolution@swift.org> a écrit :

How is it possible that higher kinded types are being discussed seriously while Python’s syntactic sugars (e.g., comprehensions) have been dismissed as too confusing?

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


(TJ Usiyan) #5

With a Cartesian Product type [like this](
https://github.com/griotspeak/CartesianProduct), the for-in-where syntax
actually gets us to list comprehensions. I'll admit that I might not have
implemented the best Cartesian Product type possible, but it should
illustrate that we have what we need.

`for case … in cartProd(cartProd(seq1, seq2), seq3) // An operator for
cartProd would make it more pleasing to read.`

···

On Thu, Dec 17, 2015 at 6:29 PM, Amir Michail via swift-evolution < swift-evolution@swift.org> wrote:

How is it possible that higher kinded types are being discussed seriously
while Python’s syntactic sugars (e.g., comprehensions) have been dismissed
as too confusing?

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


(Al Skipp) #6

That’s impressive work, but it strikes me as quite a difficult undertaking to get there. (Is it just me, or are generators and sequences the most scary part of Swift?) Also, is it possible to get it working as an expression, or is it restricted to a ‘for’ statement? If it can only be performed as a ‘for’ statement it will still need an external mutable var to be updated outside of the loop. It’s fine if you want to just do side-effecty things, like print the elements, but I’d consider the ability to return a value to be more important.

Al

···

On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

With a Cartesian Product type [like this](https://github.com/griotspeak/CartesianProduct), the for-in-where syntax actually gets us to list comprehensions. I'll admit that I might not have implemented the best Cartesian Product type possible, but it should illustrate that we have what we need.

`for case … in cartProd(cartProd(seq1, seq2), seq3) // An operator for cartProd would make it more pleasing to read.`


(TJ Usiyan) #7

Shouldn't `filter` accomplish that?

···

On Fri, Dec 18, 2015 at 7:35 AM, Al Skipp <al_skipp@fastmail.fm> wrote:

On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote:

With a Cartesian Product type [like this](
https://github.com/griotspeak/CartesianProduct), the for-in-where syntax
actually gets us to list comprehensions. I'll admit that I might not have
implemented the best Cartesian Product type possible, but it should
illustrate that we have what we need.

`for case … in cartProd(cartProd(seq1, seq2), seq3) // An operator for
cartProd would make it more pleasing to read.`

That’s impressive work, but it strikes me as quite a difficult undertaking
to get there. (Is it just me, or are generators and sequences the most
scary part of Swift?) Also, is it possible to get it working as an
expression, or is it restricted to a ‘for’ statement? If it can only be
performed as a ‘for’ statement it will still need an external mutable var
to be updated outside of the loop. It’s fine if you want to just do
side-effecty things, like print the elements, but I’d consider the ability
to return a value to be more important.

Al


(Dave Abrahams) #8

This is a much simpler cartesian product implementation:

   seq1.flatMap { x in seq2.map { (x,$0) } }

or, if you want speed,

   seq1.lazy.flatMap { x in seq2.lazy.map { (x,$0) } }

HTH,

-Dave

···

On Dec 18, 2015, at 4:35 AM, Al Skipp via swift-evolution <swift-evolution@swift.org> wrote:

On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

With a Cartesian Product type [like this](https://github.com/griotspeak/CartesianProduct), the for-in-where syntax actually gets us to list comprehensions. I'll admit that I might not have implemented the best Cartesian Product type possible, but it should illustrate that we have what we need.

`for case … in cartProd(cartProd(seq1, seq2), seq3) // An operator for cartProd would make it more pleasing to read.`

That’s impressive work, but it strikes me as quite a difficult undertaking to get there. (Is it just me, or are generators and sequences the most scary part of Swift?) Also, is it possible to get it working as an expression, or is it restricted to a ‘for’ statement? If it can only be performed as a ‘for’ statement it will still need an external mutable var to be updated outside of the loop. It’s fine if you want to just do side-effecty things, like print the elements, but I’d consider the ability to return a value to be more important.


(TJ Usiyan) #9

That is… damned nice. I choose not to feel that bad about it… for reasons.

···

On Fri, Dec 18, 2015 at 8:04 PM, Dave Abrahams <dabrahams@apple.com> wrote:

On Dec 18, 2015, at 4:35 AM, Al Skipp via swift-evolution < > swift-evolution@swift.org> wrote:

On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution < > swift-evolution@swift.org> wrote:

With a Cartesian Product type [like this](
https://github.com/griotspeak/CartesianProduct), the for-in-where syntax
actually gets us to list comprehensions. I'll admit that I might not have
implemented the best Cartesian Product type possible, but it should
illustrate that we have what we need.

`for case … in cartProd(cartProd(seq1, seq2), seq3) // An operator for
cartProd would make it more pleasing to read.`

That’s impressive work, but it strikes me as quite a difficult undertaking
to get there. (Is it just me, or are generators and sequences the most
scary part of Swift?) Also, is it possible to get it working as an
expression, or is it restricted to a ‘for’ statement? If it can only be
performed as a ‘for’ statement it will still need an external mutable var
to be updated outside of the loop. It’s fine if you want to just do
side-effecty things, like print the elements, but I’d consider the ability
to return a value to be more important.

This is a much simpler cartesian product implementation:

   seq1.flatMap { x in seq2.map { (x,$0) } }

or, if you want speed,

   seq1*.lazy*.flatMap { x in seq2*.lazy*.map { (x,$0) } }

HTH,

-Dave


(TJ Usiyan) #10

Updated the library with that. The only downside that I can see is that
flattening, as I had always planned but finally bothered to do, has no way
to tell if the left tuple was the produce of a previous cartesian product
operation. Small price to pay and all that. Thanks for the insight!

···

On Fri, Dec 18, 2015 at 8:19 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

That is… damned nice. I choose not to feel that bad about it… for reasons.

On Fri, Dec 18, 2015 at 8:04 PM, Dave Abrahams <dabrahams@apple.com> > wrote:

On Dec 18, 2015, at 4:35 AM, Al Skipp via swift-evolution < >> swift-evolution@swift.org> wrote:

On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution < >> swift-evolution@swift.org> wrote:

With a Cartesian Product type [like this](
https://github.com/griotspeak/CartesianProduct), the for-in-where syntax
actually gets us to list comprehensions. I'll admit that I might not have
implemented the best Cartesian Product type possible, but it should
illustrate that we have what we need.

`for case … in cartProd(cartProd(seq1, seq2), seq3) // An operator for
cartProd would make it more pleasing to read.`

That’s impressive work, but it strikes me as quite a difficult
undertaking to get there. (Is it just me, or are generators and sequences
the most scary part of Swift?) Also, is it possible to get it working as an
expression, or is it restricted to a ‘for’ statement? If it can only be
performed as a ‘for’ statement it will still need an external mutable var
to be updated outside of the loop. It’s fine if you want to just do
side-effecty things, like print the elements, but I’d consider the ability
to return a value to be more important.

This is a much simpler cartesian product implementation:

   seq1.flatMap { x in seq2.map { (x,$0) } }

or, if you want speed,

   seq1*.lazy*.flatMap { x in seq2*.lazy*.map { (x,$0) } }

HTH,

-Dave


(Dave Abrahams) #11

Updated the library with that. The only downside that I can see is that flattening, as I had always planned but finally bothered to do, has no way to tell if the left tuple was the produce of a previous cartesian product operation.

Not sure what that means, I’m afraid.

Small price to pay and all that. Thanks for the insight!

Glad to help.

···

On Dec 18, 2015, at 5:46 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

On Fri, Dec 18, 2015 at 8:19 PM, T.J. Usiyan <griotspeak@gmail.com <mailto:griotspeak@gmail.com>> wrote:
That is… damned nice. I choose not to feel that bad about it… for reasons.

On Fri, Dec 18, 2015 at 8:04 PM, Dave Abrahams <dabrahams@apple.com <mailto:dabrahams@apple.com>> wrote:

On Dec 18, 2015, at 4:35 AM, Al Skipp via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

With a Cartesian Product type [like this](https://github.com/griotspeak/CartesianProduct), the for-in-where syntax actually gets us to list comprehensions. I'll admit that I might not have implemented the best Cartesian Product type possible, but it should illustrate that we have what we need.

`for case … in cartProd(cartProd(seq1, seq2), seq3) // An operator for cartProd would make it more pleasing to read.`

That’s impressive work, but it strikes me as quite a difficult undertaking to get there. (Is it just me, or are generators and sequences the most scary part of Swift?) Also, is it possible to get it working as an expression, or is it restricted to a ‘for’ statement? If it can only be performed as a ‘for’ statement it will still need an external mutable var to be updated outside of the loop. It’s fine if you want to just do side-effecty things, like print the elements, but I’d consider the ability to return a value to be more important.

This is a much simpler cartesian product implementation:

   seq1.flatMap { x in seq2.map { (x,$0) } }

or, if you want speed,

   seq1.lazy.flatMap { x in seq2.lazy.map { (x,$0) } }

HTH,

-Dave

-Dave


(TJ Usiyan) #12

I was just talking about this kind of thing (I've updated the repo with up
to 5-tuples) for times where you seq1 • seq2 • seq3

// 'Cartesian product' of a Cartesian product and a collection. Meant to
help manage type explosion.

public func •<Left: SequenceType, Right: SequenceType, A, B where

    Left.Generator.Element == (A, B)>(lhs:Left, rhs:Right) -> [(A, B, Right.
Generator.Element)] {

        return lhs.flatMap { x in rhs.map { (x.0, x.1, $0) } }

}

···

On Fri, Dec 18, 2015 at 9:25 PM, Dave Abrahams <dabrahams@apple.com> wrote:

On Dec 18, 2015, at 5:46 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

Updated the library with that. The only downside that I can see is that
flattening, as I had always planned but finally bothered to do, has no way
to tell if the left tuple was the produce of a previous cartesian product
operation.

Not sure what that means, I’m afraid.

Small price to pay and all that. Thanks for the insight!

Glad to help.

On Fri, Dec 18, 2015 at 8:19 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

That is… damned nice. I choose not to feel that bad about it… for reasons.

On Fri, Dec 18, 2015 at 8:04 PM, Dave Abrahams <dabrahams@apple.com> >> wrote:

On Dec 18, 2015, at 4:35 AM, Al Skipp via swift-evolution < >>> swift-evolution@swift.org> wrote:

On 18 Dec 2015, at 00:19, T.J. Usiyan via swift-evolution < >>> swift-evolution@swift.org> wrote:

With a Cartesian Product type [like this](
https://github.com/griotspeak/CartesianProduct), the for-in-where
syntax actually gets us to list comprehensions. I'll admit that I might not
have implemented the best Cartesian Product type possible, but it should
illustrate that we have what we need.

`for case … in cartProd(cartProd(seq1, seq2), seq3) // An operator for
cartProd would make it more pleasing to read.`

That’s impressive work, but it strikes me as quite a difficult
undertaking to get there. (Is it just me, or are generators and sequences
the most scary part of Swift?) Also, is it possible to get it working as an
expression, or is it restricted to a ‘for’ statement? If it can only be
performed as a ‘for’ statement it will still need an external mutable var
to be updated outside of the loop. It’s fine if you want to just do
side-effecty things, like print the elements, but I’d consider the ability
to return a value to be more important.

This is a much simpler cartesian product implementation:

   seq1.flatMap { x in seq2.map { (x,$0) } }

or, if you want speed,

   seq1*.lazy*.flatMap { x in seq2*.lazy*.map { (x,$0) } }

HTH,

-Dave

-Dave