[swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)
matthew at anandabits.com
Wed Dec 16 21:04:17 CST 2015
Do these papers contain examples of generic use of HKTs that wouldn’t be possible with a little bit of copy and paste boilerplate? Or do they mostly contain use of concrete types that implement some typeclasses?
> On Dec 16, 2015, at 4:40 PM, T.J. Usiyan via swift-evolution <swift-evolution at swift.org> wrote:
> 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 <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 <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.
> On Wed, Dec 16, 2015 at 5:11 PM, Will Fancher via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution