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

[Andrew Bennett]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151218/3e608915/attachment.html>