[swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)

Thu Dec 17 10:01:26 CST 2015

I am actually +1 on adding HKTs eventually.  I would really like to see them in Swift.

I also think fleshing out the existing generics features is a much more immediate concern.  It's pretty clear we won't see every generics feature we can imagine in Swift 3 so we need to choose.  I would prefer to see the existing features fully fleshed out and limitations removed before we start introducing more sophisticated features into the type system.

Collecting a list of libraries you think might benefit from HKTs is a good start for providing more concrete motivation in the context of Swift.  I think a good next step would be to imagine how those libraries might look different if Swift had HKTs.  The API should ideally be comfortable for users whether they understand HKTs or not (or even know they exist).  

How would the implementations be better and the interfaces more composable and / or safer?  For the DSL examples, how would the HKT approach be superior to other approaches?  Answering these questions with hypothetical but concrete examples will do a lot to change the conversation and maybe also increase the priority.

Matthew

Sent from my iPad

> On Dec 17, 2015, at 9:40 AM, Andrew Bennett via swift-evolution <swift-evolution at swift.org> wrote:
> 
> There's a lot of passionate Swift people here, it's great to see, and I think with some clarification we could reach a consensus.
> 
> Lots of interesting discussion here for different proposals:
>  * Supporting Monads, Functors in the Standard Library
>  * Renaming flatMap, map, etc. ...
> 
> I think the second would be really interesting as a separate discussion in another proposal (ie. map/reduce is probably Term of Art https://swift.org/documentation/api-design-guidelines.html).
> 
> The current proposal is, to paraphrase:
>  * A more expressive type system through more flexible generics (HKT)
> 
> I want Swift and the Standard Library to be clean, consistent, expressive, safe, and approachable. I believe that HKTs are a necessary step to achieve all of these things.
> 
> Going back over the posts, for those talking about the proposal, this seems to be the votes so far:
> 
> Clear Votes for/against HKTs:
> Will Fancher +1
> Al Skipp +1
> Austin Zheng +1
> Dave Abrahams -1
> T.J. Usiyan +1
> Greg Titus -1
> Joe Groff +1
> Jens Persson +1
> Brent Royal-Gordon +1
> Krzysztof Siejkowski + 1
> Neutral about HKTs (expressed opinions on needing concrete examples, or FP):
> Matthew Johnson +0
> Douglas Gregor +0
> Andrey Tarantsov +0
> Noteworthy is Dave and Douglas from Apple, who basically say that either they need more examples of how this will benefit many users, or that they don't think it will.
> 
> We have collected a few examples of where this would benefit. They are mainly for generating DSLs, a DSL is by definition domain-specific, so it's going to be niche. However, DSLs in general are applicable to most apps, so perhaps there's something in that.
> 
> I think Krzysztof Siejkowski's three points are great, and we should look at and support those other threads.
> 
> We could get a representative sample of Swift code from github. Then find which of those benefit from higher kinded types:
>  * turning runtime bugs into compile-time errors
>  * reducing code-duplication, etc.
> 
> A good place to look is popular Swift libraries (top 5 on github), and see if they (and by extension their users) would benefit from HKTs:
> https://github.com/Alamofire/Alamofire (possibly, DSL)
> https://github.com/SwiftyJSON/SwiftyJSON (very likely, DSL / type constraints)
> https://github.com/SnapKit/SnapKit (very likely, chained DSL)
> https://github.com/MengTo/Spring (probably not in their DSL, maybe in their implementation)
> https://github.com/ochococo/Design-Patterns-In-Swift (probably, but I'm biased)
> Likewise there's two more cases:
> https://github.com/Quick/Quick
> https://github.com/Quick/Nimble
> They're testing frameworks, their implementation DSL could really benefit from HKTs last time I looked at it. Likewise, I'm not 100% sure but HKTs may be the building blocks upon which Swift's first convenient mocking framework could be built. Testing, and testing DSLs are things that all swift users can benefit from, the question is whether that needs HKTs.
> 
> 
> On Fri, Dec 18, 2015 at 1:43 AM, Krzysztof Siejkowski via swift-evolution <swift-evolution at swift.org> wrote:
>>> This is directed to the thread/discussion in general, not any specific person: I think it was said before but it is probably worth repeating: Whether the type system should allow HKT or not doesn't necessarily have anything to do with the names and data structures of the stdlib.
>> 
>> 
>> Well said! Could we steer the discussion in the right direction by identifying what exact features of type system are needed?
>> 
>> 
>> 
>> Some questions that come to mind:
>> 
>> 1) Do we need ability to express covariance and contravariance of generic types?
>> 
>> 2) Do we need a better mechanism for ad-hoc polymorphism, similar to Haskell's typeclasses?
>> 
>> 3) How should type constraints (`where` clause) be extended?
>> 
>> 
>> 
>> Some of those questions are already discussed in other threads, so it’s mainly a matter of ensuring that the upcoming proposals are powerful enough.
>> 
>> 
>> Krzysztof
>> 
>> 
>> 
>>> 
>>> 
>>> For example, a Mappable protocol (let's call it that rather than Functor) is currently not even _possible_ to write, and I believe this is the question to consider, i.e. whether Swift's type system should be allowed to express types that are parameterized not only by concrete types but also by parameterized types, for example if a return type could be Self<T> or just Self.
>>> 
>>> It would be sad if the question about HKT turned into yet another fruitless and meaningless functional vs imperative debate (see the talk *-Oriented Programming by Graham Lee).
>>> 
>>> /Jens
>>> 
>>>> On Thursday, December 17, 2015, Will Fancher via swift-evolution <swift-evolution at swift.org> wrote:
>>>> I'm not sure I follow? Are you suggesting that having HKTs at all will encourage Swift programmers to use bad naming conventions? I don't think the two are related unless you're talking about people using a Monad library, in which case it will be the Monad library using and encouraging bad naming conventions, not HKTs themselves.
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> --
>>> bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
>>> http://www.bitcycle.com/
>>> Phone: +46-73-753 24 62
>>> E-mail: jens at bitcycle.com
>>> 
>>> 
>>>  _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/bcc1aedf/attachment.html>