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

Thu Dec 17 09:52:35 CST 2015

I am in favor of HKT eventually, but agree that they are lower priority for
now. I do think some of these kinds of abstractions and thinking will be
more fluent for the next generation of programmers, but Swift has already
harvested the major wins in that arena by embracing enough of the power
from functional programming styles to allow us significant productivity and
expressivity wins. HKT allows more code sharing but does not prevent us
from making the practical types we need, like Future/Promise (
https://github.com/bignerdranch/Deferred for a in-the-wild implementation
that I’m involved with).

Step Christopher
Big Nerd Ranch, LLC
schristopher at bignerdranch.com

On Thu, Dec 17, 2015 at 10: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/8b9dc88e/attachment.html>