Revisiting Optionals as Sequences


(Harlan Haskins) #1

Y’know, map and flatMap being part of SequenceType is really a misnomer.

We could always just add Functor and Monad in the standard library!

protocol Functor {
    typealias A
    typealias B
    typealias FB
    
    func map(_: A -> B) -> FB
}

protocol Monad: Functor {
    static func pure(f: A) -> Self
    func flatMap(f: A -> FB) -> FB
    func >>=(x: Self, f: A -> FB) -> FB
}

infix operator >>= { associativity left }
func >>=<M: Monad>(x: M, f: M.A -> M.FB) -> M.FB {
    return x.flatMap(f)
}

···

A few months ago I sent a pair of radars (22414579 nee 22448207 and 21961711) about Optional’s extant overloading of flatMap and how it doesn’t align with either the STL or the reasons given for the closing of both radars.

> This issue behaves as intended based on the following:
>
> Yes, we are aware that this overload of flatMap could be viewed as unconventional. Nevertheless, it is useful and fits the overload set in general, if you view Optional as a sequence of zero or one T. It resembles this overload, where the closure returns an arbitrary sequence:
>
> extension SequenceType {
> public func flatMap<S : SequenceType>(transform: (Generator.Element) -> S) -> [S.Generator.Element]
> }
>
> The type checker ensures that there is no ambiguity between the two overloads, and we don't see a reason to give one of the overloads a different name (and force users to learn it, and differentiate between the two), since conceptually the operation is the same.

If Swift wishes to regard Optionals as collections with 1 or 0 elements, then I propose that it should reflect that thinking with additions to the standard library.

Possible changes include:

1) Remove or rename Optional’s flatMap.
This would cause a bit of breaking behavior, but it’s nothing some fixits couldn’t help with.

2) Add a SequenceType instance for Optional.
This kills 2 birds with 1 stone in that, if the radar rejection is to ring true, Optional should have a SequenceType instance in the STL, and such an instance would automatically come with its own proper overloading flatMap necessitating change 1.

Over in TypeLift land we’ve already implemented what we believe the SequenceType extensions should look like (https://github.com/typelift/Swiftz/blob/master/Swiftz/OptionalExt.swift#L139-L145 <https://github.com/typelift/Swiftz/blob/master/Swiftz/OptionalExt.swift#L139-L145>).


[Pitch] Conditionally conform Optional: Sequence where Wrapped: Sequence
(Lily Ballard) #2

That definition is unusable, since it restricts the type of the
map operation to be whatever type you chose when you implemented
the protocol.

To see this for yourself, try implementing Functor on Array. You can't
do it, unless you pick the B type ahead of time, and if you do that you
can only ever map() to that single type B. The map() function is
supposed to be generic on the result type of the function, but since
Swift doesn't have higher-order types there's no way to express that the
result of the map() function is the same underlying data structure with
a separate generic parameter.

-Kevin Ballard

Y’know, map and flatMap being part of SequenceType is really a
misnomer.

We could always just add Functor and Monad in the standard library!

protocol Functor { typealias A typealias B typealias FB

func map(_: A -> B) -> FB }

protocol Monad: Functor { static func pure(f: A) -> Self func
flatMap(f: A -> FB) -> FB func >>=(x: Self, f: A -> FB) -> FB }

infix operator >>= { associativity left } func >>=<M: Monad>(x: M, f:
M.A -> M.FB) -> M.FB { return x.flatMap(f) }

A few months ago I sent a pair of radars (22414579 nee 22448207 and
21961711) about Optional’s extant overloading of flatMap and how it
doesn’t align with either the STL or the reasons given for the
closing of both radars.

* This issue behaves as intended based on the following:

*>**>* Yes, we are aware that this overload of flatMap could be viewed
as unconventional. Nevertheless, it is useful and fits the overload set
in general, if you view Optional as a sequence of zero or one T. It
resembles this overload, where the closure returns an arbitrary
sequence: *>**>* extension SequenceType { *>* public func flatMap<S :

(transform: (Generator.Element) -> S) ->

[S.Generator.Element] *>* } *>**>* The type checker ensures that there
is no ambiguity between the two overloads, and we don't see a reason to
give one of the overloads a different name (and force users to learn it,
and differentiate between the two), since conceptually the operation is
the same. * If Swift wishes to regard Optionals as collections with 1 or
0 elements, then I propose that it should reflect that thinking with
additions to the standard library.

Possible changes include:

1) Remove or rename Optional’s flatMap. This would cause a bit of
   breaking behavior, but it’s nothing some fixits couldn’t help with.

2) Add a SequenceType instance for Optional. This kills 2 birds with 1
   stone in that, if the radar rejection is to ring true, Optional
   should have a SequenceType instance in the STL, and such an instance
   would automatically come with its own proper overloading flatMap
   necessitating change 1.

Over in TypeLift land we’ve already implemented what we believe the
SequenceType extensions should look like (https://github.com/typelift/-
Swiftz/blob/master/Swiftz/OptionalExt.swift#L139-L145
<https://github.com/typelift/Swiftz/blob/master/Swiftz/OptionalExt.swift#L139-L145>
).

···

On Fri, Dec 4, 2015, at 08:56 PM, Harlan Haskins wrote:

_________________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Robert Widmann) #3

Oh please, please, never let those leave TypeLift's repositories until HKTs get merged... :stuck_out_tongue:

I guess what I want is consistency, either of implementation or of terminology. Because right now the language has neither and is trampling a function with a very consistent, rigorous definition for what I'm not sure?

~Robert Widmann

2015/12/04 23:56、Harlan Haskins <harlan@harlanhaskins.com> のメッセージ:

···

Y’know, map and flatMap being part of SequenceType is really a misnomer.

We could always just add Functor and Monad in the standard library!

protocol Functor {
    typealias A
    typealias B
    typealias FB
    
    func map(_: A -> B) -> FB
}

protocol Monad: Functor {
    static func pure(f: A) -> Self
    func flatMap(f: A -> FB) -> FB
    func >>=(x: Self, f: A -> FB) -> FB
}

infix operator >>= { associativity left }
func >>=<M: Monad>(x: M, f: M.A -> M.FB) -> M.FB {
    return x.flatMap(f)
}

A few months ago I sent a pair of radars (22414579 nee 22448207 and 21961711) about Optional’s extant overloading of flatMap and how it doesn’t align with either the STL or the reasons given for the closing of both radars.

> This issue behaves as intended based on the following:
>
> Yes, we are aware that this overload of flatMap could be viewed as unconventional. Nevertheless, it is useful and fits the overload set in general, if you view Optional as a sequence of zero or one T. It resembles this overload, where the closure returns an arbitrary sequence:
>
> extension SequenceType {
> public func flatMap<S : SequenceType>(transform: (Generator.Element) -> S) -> [S.Generator.Element]
> }
>
> The type checker ensures that there is no ambiguity between the two overloads, and we don't see a reason to give one of the overloads a different name (and force users to learn it, and differentiate between the two), since conceptually the operation is the same.

If Swift wishes to regard Optionals as collections with 1 or 0 elements, then I propose that it should reflect that thinking with additions to the standard library.

Possible changes include:

1) Remove or rename Optional’s flatMap.
This would cause a bit of breaking behavior, but it’s nothing some fixits couldn’t help with.

2) Add a SequenceType instance for Optional.
This kills 2 birds with 1 stone in that, if the radar rejection is to ring true, Optional should have a SequenceType instance in the STL, and such an instance would automatically come with its own proper overloading flatMap necessitating change 1.

Over in TypeLift land we’ve already implemented what we believe the SequenceType extensions should look like (https://github.com/typelift/Swiftz/blob/master/Swiftz/OptionalExt.swift#L139-L145).