<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Did anything become of this…. This seemed to die out with no proposal.<div class=""><br class=""></div><div class="">I would think having a common protocol for types that support monadic operations (regardless if they fulfill all the monadic operations) would generally be helpful — even if they were not implemented theoretically as a Functor / Monad separate protocol definitions. </div><div class=""><br class=""></div><div class="">Scala seems to just treat them as one set of operations (MonadOps : map, flatMap, filter, withFilter). `filter` copies the contents into a new set, `withFilter` is just an on-demand filter for any later functions such as map/flatmap (BTW, Is swift filter on-demand, copy, or a combination???). I do notice that several different implement of the Monad protocol have been done in different repositories - by third parties. </div><div class=""><br class=""></div><div class="">And yes, Optionals are monads - and as such can be used in comprehension clauses.</div><div class=""><br class=""></div><div class="">I know that for-comprehension has been stated as probably not a Swift 3 thing (Felix indicated this but I don’t know where it is stated) - but I am wondering if they are thinking it is larger than it actually is (being that it is just a more friendly way to state existing map/flatmap combinations). If the worry is `for` having dual purpose — but if that is the case maybe making a new keyword for comprehensions like `all`.</div><div class=""><br class=""></div><div class="">Even if the proposal were drawn up - and it was `Deferred` at least it would potentially be on the radar.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 2015-12-18, at 1:01:21, André Videla via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">I'm extremely excited about HKT. Huge +1 for me as well. </div><div class=""><br class=""></div><div class="">Moreover, <span style="background-color: rgba(255, 255, 255, 0);" class="">In addition to lots of code reuse,</span> this would allow to extend the language with very expressive and useful syntax for monadic types. </div><div class="">Monadic comprehension are very useful and generic. </div><div class="">We could imagine something the for-comprehension in scala and use it with list comprehension as well as parser combinators. </div><div class=""><br class=""></div><div class="">I sincerely hope this feature will see the day. </div><div class=""><br class=""><div class=""><br class=""><br class="">Sent from my iPod</div>On 2015/12/17, at 17:44, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""></div><div class="">Big +1 for HKTs from me!</div><div class=""><br class=""></div><div class="">-Thorsten </div><div class=""><br class="">Am 17.12.2015 um 13:10 schrieb Will Fancher via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">Optional.map and Array.map do different things, and unifying them seems harmful.</div></div></div></blockquote><div class=""><br class=""></div><div class="">In terms of category theory, they're not different. They are both arrows from a to b in the Functor category. Obviously that's horribly abstract, so I'll put it this way: If you think of these map functions not as operations on Optional and Array, and instead think of them simply as ways to compose an arbitrary data structure, they are in fact doing the same thing. On an implementation level, and on a runtime level, they perform differently. But on a type level, a theoretical level, and a categorical level, they are the same. You merely need to accept that when using this abstraction without knowledge of the concrete type, you have no reason to make any assumptions about how the implementation and runtime will behave. At that point, all you need is to be sure that the Functor being passed in abides by the Functor laws, and that's just a matter of convention.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">First, I consider myself a smart person with a very broad experience with non-functional languages, but reading this makes my mind hurt, a lot:</div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""> typeclass Functor f where<br class=""> fmap :: (a -> b) -> f a -> f b</div></div></blockquote><snip><br class=""><blockquote type="cite" class=""><div class=""><div class="">This makes it possible to build functions which operate not just on Maybe, but on any Functor.</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><br class=""> fstrlen :: Functor f => f String -> f Int<br class=""> fstrlen fstr = fmap length faster</div></div></blockquote><snip><br class=""><blockquote type="cite" class=""><div class=""><div class=""> protocol Functor {<br class=""> typealias A<br class=""> func fmap<FB where FB ~= Self>(f: A -> FB.A) -> FB<br class=""> }<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I understand what's going on here, but I never, ever want to see this code anywhere near (my) Swift.</div></div></div></div></blockquote><br class=""></div><div class="">HKTs that come from category theory tend to have this effect. They are hard to understand by reading the protocol definition. Admittedly, this is a big flaw with Monads and with Haskell. It takes a reasonable understanding of category theory for the purpose of this code to be obvious to the reader.</div><div class=""><br class=""></div><div class="">(I will point out that in those code examples, I used absolutely abysmal naming conventions. It could be made marginally more readable and understandable if the naming were better)</div><div class=""><br class=""></div><div class="">I'll take this time to make the point that just because you don't like the way the Functor protocol looks, doesn't mean Array and Optional aren't both Functors and Monads. As a matter of mathematics, if the Monad functions can exist on a type, and they would follow the Monad laws, that type is a Monad whether the implementor likes it or not. Of course it still needs manual implementing, but regardless, the type is theoretically a Monad. (This realization is the reason that the Java team decided to implement flatMap for Java 8's Optional class.)</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">I believe the way to convince the rest of us (and I would love to be convinced) is to provide a few real, “end-user” app-level use cases and explain the benefit in plain language. In particular, I don't understand the example by Jens Persson, although it seems like a valuable one.</blockquote></div><br class=""><div class="">I can (again) link to just a few of the abstract Monadic functions, all of which are very useful in practical applications.</div><div class=""><br class=""></div><div class=""><a href="https://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Monad.html" class="">https://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Monad.html</a></div><div class=""><br class=""></div><div class="">But perhaps it would also help to describe the architectural decisions that abiding by Monad imposes.</div><div class=""><br class=""></div><div class="">Being Monadic makes you think about data composition, which cleans up the way you design your code. Going back to the Futures example, I could implement future, and subsequently use it, like this:</div><div class=""><br class=""></div><div class=""><div class=""> public class Promise<T> {</div><div class=""> private var handlers: [T -> ()] = []</div><div class=""> private var completed: T? = nil</div><div class=""> </div><div class=""> public init() {</div><div class=""> }</div><div class=""> </div><div class=""> private func onComplete(handler: T -> ()) {</div><div class=""> if let completed = completed {</div><div class=""> handler(completed)</div><div class=""> } else {</div><div class=""> handlers.append(handler)</div><div class=""> }</div><div class=""> }</div><div class=""> </div><div class=""> public func complete(t: T) {</div><div class=""> completed = t</div><div class=""> for handler in handlers {</div><div class=""> handler(t)</div><div class=""> }</div><div class=""> handlers = []</div><div class=""> }</div><div class=""> </div><div class=""> public var future: Future<T> {</div><div class=""> return Future(promise: self)</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class=""> public struct Future<T> {</div><div class=""> private let promise: Promise<T></div><div class=""> </div><div class=""> private init(promise: Promise<T>) {</div><div class=""> self.promise = promise</div><div class=""> }</div><div class=""> </div><div class=""> public func onComplete(handler: T -> ()) {</div><div class=""> promise.onComplete(handler)</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class=""> public func useFutures() {</div><div class=""> downloadURLInFuture().onComplete { content in</div><div class=""> processContentAsync(content).onComplete { processed in</div><div class=""> processed.calculateSomethingAsync().onComplete {</div><div class=""> ...</div><div class=""> ...</div><div class=""> print(finalProduct)</div><div class=""> ...</div><div class=""> ...</div><div class=""> }</div><div class=""> }</div><div class=""> }</div><div class=""> }</div></div><div class=""><br class=""></div><div class="">You can see how this resembles the infamous Node.js issue of callback hell, and how the nesting could quickly get out of hand. If only we had some form of composition... Arrows between Futures... Luckily, Future is a Monad (whether I like it or not!)</div><div class=""><br class=""></div><div class=""><div class=""> // Monad</div><div class=""><br class=""></div><div class=""> public extension Future {</div><div class=""> public static func point<T>(t: T) -> Future<T> {</div><div class=""> let promise = Promise<T>()</div><div class=""> promise.complete(t)</div><div class=""> return promise.future</div><div class=""> }</div><div class=""> </div><div class=""> public func flatMap<U>(f: T -> Future<U>) -> Future<U> {</div><div class=""> let uPromise = Promise<U>()</div><div class=""> </div><div class=""> onComplete { t in</div><div class=""> f(t).onComplete { u in</div><div class=""> uPromise.complete(u)</div><div class=""> }</div><div class=""> }</div><div class=""> </div><div class=""> return uPromise.future</div><div class=""> }</div><div class=""> }</div></div><div class=""><br class=""></div><div class="">Not only do I now get map and apply for free, but I also get a great method of composing Futures. The example from above can now be rewritten to be much more well composed.</div><div class=""><br class=""></div><div class=""><div class=""> public func useFutures() {</div><div class=""> downloadURLInFuture()</div><div class=""> .flatMap(processContentAsync)</div><div class=""> .flatMap { $0.calculateSomethingAsync() }</div><div class=""> ...</div><div class=""> .onComplete { finalProduct in</div><div class=""> print(finalProduct)</div><div class=""> }</div><div class=""> }</div></div><div class=""><br class=""></div><div class="">The important thing here is that thinking about Monads helped me discover a better composition model. Now my code can be more readable and well composed.</div><div class=""><br class=""></div></div></div><div class="">And again, I'll mention the enormous world of functions and capabilities that can be gotten for free for the sake of even more well-composed code.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">I don't want a flatMap on optionals (which, I believe, was thankfully removed in Swift 2).</div></blockquote><br class=""></div><div class="">And why on Earth not? The concrete implementation of it on Optional is very simple and easy to understand, and the method is incredibly useful. Personally, I use it all the time (it was not removed). And again, just because you don't like using flatMap doesn't mean Optional isn't a Monad.</div><div class=""><br class=""></div><div class="">Finally, I'd like to point out that it doesn't hurt any end users not familiar with Monads if Array implements a higher kinded Monad protocol. As far as they have to be concerned, Array just has these useful map and flatMap functions. Meanwhile, those of us who wish to abstract over Monads in general can write our abstract code and implement Monad on our various types which mathematically have to be Monads. It's a layer of robustness and improvement that unconcerned end users don't have to bother themselves with.</div><div class=""><br class=""></div><div class="">While I understand that the Swift team doesn't have the resources to implement everything that everyone wants, and that HKTs aren't very high on their list of priorities, it seems unreasonable to me that one could think of HKTs and Monads as somehow detrimental to the language.</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=1MXK54sosN3xru3iYcLt0oBZ2w20i49gyogXctgrspdifEc60hd-2FHHx-2FDnKudeVTXrrb-2FFnn4MJmMn8vFm01f3NiitschCpQupPvTkee0q5FSL5bHWTN9CBSedsJCI7y1MHrWE7o3WykKEUEhI3BQxvyqghzMvUvsR-2FICpnwQ-2FrBNHzYDuIwRbx6iNRIPr7k0mFmglrz02DzbkZ40DHDRE3d-2Fe80x7jFEZaUG7rkXH8-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=41N46VivWCZSszJfIBo5GomxU0lRtHzu03OKlyxSC0VmJB-2FS2kx7yBffBBSF6Vdeg4hp9OdcL-2FGabniBXk-2FnOQMzweds7hDrVBzRQA-2Bvb-2FFM28PQa3t8PAwSQD8RFxIAZFQlYABL4F4LNsQwMzwMmFZb2CfBWPEPHlwt69R7dvV3NOgwIL3EeH2-2FpLBu9meVi4Q7uz42J2u-2FbddIUxqHaQ-3D-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=CGU22LnxbYa2EM3wKvzuC6syQDwKa0tMs5IyT5gL1wL9V67jA1zoQrCOtpNGByIQPhWHFSuKSSRWQNAfclw13EoSczEoAmNXrJE7oYADGqVb5Kym-2Fq7wDK4Q-2BJnbS9KI-2BNfCvs2ovBEloO2aPy-2FLP8hLNGLjRzOFQ6ENlH325UWguJ6XquU-2B7zTxI8rqPovsF3jY3OVKiuXCy3-2BxrhesZbDZubkJQiCFyfrnrea9h5c-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>