<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><br><div id="AppleMailSignature">Sent from my iPad</div><div><br>On Dec 13, 2017, at 11:13 PM, Stephen Celis <<a href="mailto:stephen.celis@gmail.com">stephen.celis@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><blockquote type="cite"><span>On Dec 13, 2017, at 9:53 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Chris L had a beautiful solution for an "Unwrappable" protocol that allowed all of the optional sugar to be extended to any type that had a biased `Wrapped` item, allowing it to be used with `Either`, `Wrapped`, etc as well as form the basis for `Optional` itself.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>protocol Unwrappable {</span><br></blockquote><blockquote type="cite"><span> associatedtype Element</span><br></blockquote><blockquote type="cite"><span> func unwrap() -> Element?</span><br></blockquote><blockquote type="cite"><span>}</span><br></blockquote><span></span><br><span>It would definitely be nice to make "Optional" sugar work for non-"Optional" types! (I think the goal for "async"/"await" is to make it work for any continuation, so it's basically Haskell "do" notation for Swift!)</span><br><span></span><br><span>I'm not sure the "Unwrappable" protocol can handle many of the examples I mentioned (accumulative errors, parallelism), though I wonder if it could be designed differently to do so. The applicative structure requires just 2 functions[1]:</span><br><span></span><br><span> protocol Applicative<A>: Functor<A> {</span><br><span> static func pure(_ value: A) -> Self</span><br><span> static func <*> <B>(lhs: Self<(A) -> B>, rhs: Self) -> Self<B> </span><br><span> }</span><br><span></span><br><span>Such a protocol isn't possible in Swift (yet), </span></div></blockquote><div><br></div><div>Thanks for jumping in and elaborating on a more general approach! I don’t want to sidetrack the thread, but it actually is possible to encode higher-kindred types and protocols requiring them in Swift today. It’s a bit clunky and requires some boilerplate but the technique is worth knowing. <a href="https://gist.github.com/anandabits/f12a77c49fc002cf68a5f1f62a0ac9c4">https://gist.github.com/anandabits/f12a77c49fc002cf68a5f1f62a0ac9c4</a></div><div><br></div><div>Some Kotlin folks have created a pretty robust FP library using the same technique: <a href="http://kategory.io/">http://kategory.io/</a>.</div><br><blockquote type="cite"><div><span>but it could unlock this kind of sugar for everyone. Here's "Optional" conformance:</span><br><span></span><br><span> extension Optional: Applicative<Wrapped> {</span><br><span> static func pure(_ value: Wrapped) -> Wrapped? {</span><br><span> return value // promoted to Optional.some</span><br><span> }</span><br><span></span><br><span> static func <*> <B>(lhs: Optional<(Wrapped) -> B>, rhs: Optional) -> B? {</span><br><span> guard let lhs = lhs, rhs = rhs else { return nil }</span><br><span> return lhs(rhs)</span><br><span> }</span><br><span> }</span><br><span></span><br><span>We can't conform to such an "Applicative" protocol today, but we _can_ still write and use these functions in a concrete manner! (Delete the conformance and see!)</span><br><span></span><br><span>The original post in this thread had this example:</span><br><span></span><br><span> getPostageEstimate(source: String, destination: String, weight: Double)</span><br><span></span><br><span>If we were dealing with this function in the world of optional arguments, here's how we could use our abstraction:</span><br><span></span><br><span> Optional.pure(curry(getPostageEstimate)) <*> john.address <*> alice.address <*> pure(2.0)</span><br><span></span><br><span>It's not _too_ bad, though it's kinda noisy, we have to maintain a bunch of custom code, we have to curry "getPostageEstimate" before passing it through, we lose our argument labels, and we're living in custom operator world, which can be disconcerting at first.</span><br><span></span><br><span>If Swift provided sugar over this structure, we'd merely need to do this:</span><br><span></span><br><span> getPostageEstimate(|source: john.address, destination: alice.address, weight: 2.0|)</span><br><span></span><br><span>What's even neater is we can use this same format for types that wrap values in other ways! Let's say the addresses are coming from untrusted sources and need to be validated:</span><br><span></span><br><span> getPostageEstimate(|source: try validateAddr(john), destination: try validateAddr(alice), weight: 2.0|)</span><br><span></span><br><span>If both addresses are invalid and "throw", we could get both errors and render them at once to our end user.</span><br><span></span><br><span>Another example: what if we want to get the postage estimate for two addresses that we need to fetch asynchronously:</span><br><span></span><br><span> getPostageEstimate(|source: await myAddress(), destination: await theirAddress(), weight: 2.0|)</span><br><span></span><br><span>Such a syntax allows those requests to run in parallel and not block :)</span><br><span></span><br><span>In these examples, "Optional" promotion becomes applicative promotion ("2.0" is getting wrapped automatically), which might open a can of worms but it's a fun can to think about!</span><br><span></span><br><span></span><br><span>--</span><br><span>[1]: Well, technically it also requires "map", since any applicative is a functor, and it also requires that it follows some math laws.</span><br><span></span><br><span></span><br><span>Stephen</span></div></blockquote></body></html>