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

[T.J. Usiyan]

I am for this but I am sure that we won't get it in Swift 3. I do hope that
we at least consider it enough to ensure that the ABI supports it to some
extent.

TJ

On Wed, Dec 16, 2015 at 8:36 AM, Andrew Bennett via swift-evolution <
swift-evolution at swift.org> wrote:

> +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
>>
>>
>
> _______________________________________________
> 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/20151216/41f8b8ad/attachment.html>