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

[T.J. Usiyan]

The ideal situation would involve being able to represent monad and being
able to type alias the behavior that that would afford us 'for free' to
specific named functions methods for our specific types, I think.

The concrete example of a HKT's usefullness that I am after is captured
here with [Causal Commutative Arrows](
http://cs.yale.edu/c2/images/uploads/ICFP-CCA.pdf). I admit that the big
win has to do with the compile time optimization afforded, but I will argue
that the syntax's similarity to audio related pseudocode is just as big of
a win. [These slides](
http://static1.squarespace.com/static/53e04d59e4b0c0da377d20b1/t/541cb6eee4b0be37af62e23f/1411167982496/nichoiceICFP2014Presentation.pdf)
give a hint at what I am talking about. I agree that using "Monad"
everywhere is not generally descriptive but I think that that is simply an
issue of being able to document intent.

TJ

On Wed, Dec 16, 2015 at 5:11 PM, Will Fancher via swift-evolution <
swift-evolution at swift.org> wrote:

> Admittedly, the majority of my reasoning for higher kinded types comes
> from wanting Monads to be an available abstraction. I've been writing a lot
> of generic code, and finding that a lot of my types are Monads, which leads
> me to repeat many functions for each of these types, when those functions
> could be abstracted.
>
> The fact is, most generic types can be Functors, and a lot of them can be
> Monads. Therefore, having generics at all suggests that the language will
> have a lot of these kinds of types. The standard library doesn't have many.
> Optionals and the various collection protocols make up the majority of
> them. So developers who can rely mostly on the standard library using
> concrete types probably have everything they need in this area. But
> creating one's own generic types will very often lead to reimplementing the
> same Monad / Applicative / Functor utility functions. I can't tell you how
> many times I've copy-pasted my sequence function and changed only the type
> signature. Futures, Eithers, and Streams are three examples of types I've
> been implementing as Monads, which has lead to a lot of repetition.
>
> It is my personal opinion that Monads come up often enough that having
> proper support for them would be worthwhile. But I suppose the average
> Swift programmer may not run into these things as often as I do, so it
> makes sense that HKTs are low on the Swift team's priorities.
> _______________________________________________
> 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/20151216/d17c63f8/attachment.html>