<div dir="ltr">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.<div><br></div><div>The concrete example of a HKT's usefullness that I am after is captured here with [Causal Commutative Arrows](<a href="http://cs.yale.edu/c2/images/uploads/ICFP-CCA.pdf">http://cs.yale.edu/c2/images/uploads/ICFP-CCA.pdf</a>). 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](<a href="http://static1.squarespace.com/static/53e04d59e4b0c0da377d20b1/t/541cb6eee4b0be37af62e23f/1411167982496/nichoiceICFP2014Presentation.pdf">http://static1.squarespace.com/static/53e04d59e4b0c0da377d20b1/t/541cb6eee4b0be37af62e23f/1411167982496/nichoiceICFP2014Presentation.pdf</a>) 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.</div><div><br></div><div>TJ</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 5:11 PM, Will Fancher via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>