<div dir="ltr">The concrete example in those links is a DSL for audio related programming. I thought that I presented the point in that paragraph but I will try to summarize.<div><br></div><div>Using Arrows, which are a specific HKT, allows us to write audio code which resembles the description of certain audio operations more closely than typical procedural code. This, all by itself, is a big win. Certain optimizations are proven safe if we use a controlled subset of arrows. These optimizations allow the code–which tends to represent many loops–to be rewritten as one loop accepting a ball of coalesced state. This optimized code is exceptionally fast and provides the second win. </div><div><br></div><div>TLDR, Audio signal flow code benefits greatly from specific HKT.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 6:49 PM, Douglas Gregor <span dir="ltr">&lt;<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Dec 16, 2015, at 2:40 PM, T.J. Usiyan &lt;<a href="mailto:griotspeak@gmail.com" target="_blank">griotspeak@gmail.com</a>&gt; wrote:</div><br><div><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 &#39;for free&#39; to specific named functions methods for our specific types, I think.<div><br></div><div>The concrete example of a HKT&#39;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" target="_blank">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&#39;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" target="_blank">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 &quot;Monad&quot; everywhere is not generally descriptive but I think that that is simply an issue of being able to document intent.</div></div></div></blockquote><br></div></span><div>I’d just like to point out that I’ve been asking for concrete examples of how Swift programmers would benefit from higher-kinded types in their daily development, but I’ve received links to ICFP papers and lists of Haskell abstractions (Monad, Functor, Applicative) that only a type-theorist can understand. At best, this is a public-relations problem for higher-kinded types, because the vast majority of Swift developers—and also of members of this list—won’t be able to readily translate the content behind those links into “how does this improve my Swift code?” At worst, it’s a signal that this feature might not be of practical relevance to Swift, either because it solves problems Swift programmers don’t have or because it requires a thorough reading of TaPL to understand.</div><div><br></div><div><span style="white-space:pre-wrap">        </span>- Doug</div><div><br></div><br></div></blockquote></div><br></div>