<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="">A tentative -1, based on the following two personal opinions:<div class=""><br class=""></div><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><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><br class=""></div><div>I understand what's going on here, but I never, ever want to see this code anywhere near (my) Swift.</div></div><div><br class=""></div><div><br class=""></div><div>Second, I consider this an anti-pattern:</div><div><br class=""></div><div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">func sayHello(name: Optional<String>) -> Optional<String> {</div><div class="">func sayHello(name: Array<String>) -> Array<String> {<br class=""></div><div class="">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…).</div><img alt="" width="1" height="1" border="0" class="" style="border-width: 0px !important; margin: 0px !important; padding: 0px !important;" apple-inline="yes" id="6F325768-FDAE-47A9-A90D-E57B970E8995" apple-width="yes" apple-height="yes" src="cid:F7762472-E07E-4798-8D23-309991F149EB"></div></blockquote><div><br class=""></div>Optional.map and Array.map do different things, and unifying them seems harmful.</div><div><br class=""></div><div><br class=""></div><div>I'm yet to see a compelling case where monads are useful either, for a real job (and not as a workaround for the idiosyncrasies of the type system).</div><div><br class=""><br class=""></div></div><div>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.</div><div><br class=""></div><div>A.</div><div><br class=""></div></body></html>