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

[T.J. Usiyan]

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.

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.

TLDR, Audio signal flow code benefits greatly from specific HKT.

On Wed, Dec 16, 2015 at 6:49 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Dec 16, 2015, at 2:40 PM, T.J. Usiyan <griotspeak at gmail.com> 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). 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.
>
>
> 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.
>
> - Doug
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/17aae816/attachment.html>