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

[Andrew Bennett]

+100 to this.

I'm not a huge fan of ~= syntax, but higher kinded types are something
swift would benefit greatly from, particularly with stronger more concise
type constraints, more code reuse.

Another example, one I'm very keen on achieving, is this:

With Swift 1.2 how do you implement map on CollectionType that returns the
same type of collection?

Give it a go, I learnt a lot failing! You're aiming to be able to do this:

extension CollectionType {
    func myMap ....
}

let myDictionary: [String:Int] = ["test": 1]
var otherDictionary = myDictionary.myMap { ($0, Float($1)) }

// does not fail:

assert(otherDictionary is [String:Float])

let myArray: [Int] = [1]

// error: cannot convert '[Float]' to specified type '[String : Float]'

otherDictionary = myOptional.myMap { Float($0) }


The caveats are:
 *  it has to work regardless of what is implementing CollectionType, and
 * it can't have an ambiguous return type

With higher kinded types you could do something like this:

extension CollectionType {
    func myMap<G: GeneratorType>(transform: Generator.Element->G.Element)
-> Self<G> {
        return Self(sequence: AnySequence(self).forEach(transform))
    }
}



On Wed, Dec 16, 2015 at 11:39 PM, Al Skipp via swift-evolution <
swift-evolution at swift.org> wrote:

> On 16 Dec 2015, at 11:11, Will Fancher via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hello,
>
> A potent problem in my experience with Swift has been the lack of a way to
> generalize code that is repetitive on the basis of higher kinded types. For
> the uninitiated, higher kinded types are the ability to reason about
> generic types with their type parameters as variable.
>
>
> For those thinking, “Hmm… What’s the benefit of all this crazy sounding
> stuff?”, there’s a rather good practical talk about Functors.
>
> *How I Learned to Stop Worrying and Love the Functor:*
> https://vimeo.com/132657092
>
>
> Here’s an example that is used:
>
> func sayHello(name: Optional<String>) -> Optional<String> {
>   return name.map { "Hello \($0)" }
> }
>
> func sayHello(name: Array<String>) -> Array<String> {
>   return name.map { "Hello \($0)" }
> }
>
> It doesn’t use the usual syntax sugar for Optionals and Array, to make it
> clear that the only difference between the 2 functions is the type
> signature. If were possible to express the concept of a Functor, we could
> write one function that would accept both Optionals and Arrays as
> parameters – and not just those 2, but any Functor (Result, Future,
> Signal…).
>
> _______________________________________________
> 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/20151217/d8a1dc4e/attachment.html>