<div dir="ltr"><div>There's a lot of passionate Swift people here, it's great to see, and I think with some clarification we could reach a consensus.</div><div><br></div><div><div>Lots of interesting discussion here for different proposals:</div><div> * Supporting Monads, Functors in the Standard Library</div><div> * Renaming flatMap, map, etc. ...</div><div><div><br></div><div>I think the second would be really interesting as a separate discussion in another proposal (ie. map/reduce is probably Term of Art <a href="https://swift.org/documentation/api-design-guidelines.html" target="_blank">https://swift.org/documentation/api-design-guidelines.html</a>).</div><div><br></div><div>The current proposal is, to paraphrase:<div> * A more expressive type system through more flexible generics (HKT)</div></div><div><br></div><div>I want Swift and the Standard Library to be clean, consistent, expressive, safe, and approachable. I believe that HKTs are a necessary step to achieve all of these things.</div><div><br></div><div>Going back over the posts, for those talking about the proposal, this seems to be the votes so far:</div><div><br></div><div><b>Clear Votes for/against HKTs:</b><br></div><div><ul><li><span style="font-size:13px;white-space:nowrap">Will Fancher +1</span><br></li><li><span style="font-size:13px">Al Skipp +1</span></li><li><span style="font-size:13px"><span style="white-space:nowrap">Austin Zheng +1</span></span></li><li><span style="font-size:13px">Dave Abrahams -1</span></li><li>T.J. Usiyan +1</li><li><span style="font-size:13px;white-space:nowrap">Greg Titus -1</span><br></li><li><span style="font-size:13px;white-space:nowrap">Joe Groff +1</span></li><li><span style="font-size:13px;white-space:nowrap">Jens Persson +1</span></li><li>Brent Royal-Gordon +1</li><li>Krzysztof Siejkowski + 1</li></ul><div><b>Neutral about HKTs (expressed opinions on needing concrete examples, or FP):</b><br><ul><li>Matthew Johnson +0</li><li>Douglas Gregor +0</li><li><span style="font-size:13px;white-space:nowrap">Andrey Tarantsov +0</span></li></ul></div></div></div></div>Noteworthy is Dave and Douglas from Apple, who basically say that either they need more examples of how this will benefit many users, or that they don't think it will.<div><br></div><div>We have collected a few examples of where this would benefit. They are mainly for generating DSLs, a DSL is by definition domain-specific, so it's going to be niche. However, DSLs in general are applicable to most apps, so perhaps there's something in that.</div><div><br></div>I think Krzysztof Siejkowski's three points are great, and we should look at and support those other threads.<div><br></div><div>We could get a representative sample of Swift code from github. Then find which of those benefit from higher kinded types:</div><div> * turning runtime bugs into compile-time errors</div><div> * reducing code-duplication, etc.</div><div><br></div><div>A good place to look is popular Swift libraries (top 5 on github), and see if they (and by extension their users) would benefit from HKTs:</div><div><ul><li><a href="https://github.com/Alamofire/Alamofire">https://github.com/Alamofire/Alamofire</a> (possibly, DSL)<br></li><li><a href="https://github.com/SwiftyJSON/SwiftyJSON">https://github.com/SwiftyJSON/SwiftyJSON</a> (very likely, DSL / type constraints)<br></li><li><a href="https://github.com/SnapKit/SnapKit">https://github.com/SnapKit/SnapKit</a> (very likely, chained DSL)<br></li><li><a href="https://github.com/MengTo/Spring">https://github.com/MengTo/Spring</a> (probably not in their DSL, maybe in their implementation)<br></li><li><a href="https://github.com/ochococo/Design-Patterns-In-Swift">https://github.com/ochococo/Design-Patterns-In-Swift</a> (probably, but I'm biased)</li></ul><div>Likewise there's two more cases:</div></div><div><ul><li><a href="https://github.com/Quick/Quick">https://github.com/Quick/Quick</a><br></li><li><a href="https://github.com/Quick/Nimble">https://github.com/Quick/Nimble</a><br></li></ul><div>They're testing frameworks, their implementation DSL could really benefit from HKTs last time I looked at it. Likewise, I'm not 100% sure but HKTs may be the building blocks upon which Swift's first convenient mocking framework could be built. Testing, and testing DSLs are things that all swift users can benefit from, the question is whether that needs HKTs.</div></div><div><div><div><span style="white-space:nowrap"><br></span></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 18, 2015 at 1:43 AM, Krzysztof Siejkowski via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div><blockquote type="cite" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span><div><div>This is directed to the thread/discussion in general, not any specific person: I think it was said before but it is probably worth repeating: Whether the type system should allow HKT or not doesn't necessarily have anything to do with the names and data structures of the stdlib.</div></div></span></blockquote></div><p><br></p></span><p>Well said! Could we steer the discussion in the right direction by identifying what exact features of type system are needed?</p><p><br></p><p>Some questions that come to mind:</p><p>1) Do we need ability to express covariance and contravariance of generic types?</p><p>2) Do we need a better mechanism for ad-hoc polymorphism, similar to Haskell's typeclasses?</p><p>3) How should type constraints (`where` clause) be extended?</p><div><br></div><div><br></div><div>Some of those questions are already discussed in other threads, so it’s mainly a matter of ensuring that the upcoming proposals are powerful enough.</div><p><br></p><p>Krzysztof</p><p><br></p><div><blockquote type="cite" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span><div><div><span class=""><div><br><br></div><div>For example, a Mappable protocol (let's call it that rather than Functor) is currently not even _possible_ to write, and I believe this is the question to consider, i.e. whether Swift's type system should be allowed to express types that are parameterized not only by concrete types but also by parameterized types, for example if a return type could be Self<T> or just Self.<div><br></div><div>It would be sad if the question about HKT turned into yet another fruitless and meaningless functional vs imperative debate (see the talk *-Oriented Programming by Graham Lee).<br><div><br></div><div>/Jens<br><br>On Thursday, December 17, 2015, Will Fancher via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I'm not sure I follow? Are you suggesting that having HKTs at all will encourage Swift programmers to use bad naming conventions? I don't think the two are related unless you're talking about people using a Monad library, in which case it will be the Monad library using and encouraging bad naming conventions, not HKTs themselves.<br>_______________________________________________<br>swift-evolution mailing list<br><a>swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></blockquote></div></div></div><br><br>--<br>bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: <a href="tel:%2B46-73-753%2024%2062" value="+46737532462" target="_blank">+46-73-753 24 62</a><br>E-mail:<span> </span><a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br><br></span><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=07Gw-2BHYt-2F8PHoGiImISMGgoJA8YAyCkVdtiMuRGm10Gz5DTQfneQERwpMnCGLsBd6fBcHnBIOxkfJlBd0at6s-2F5bPXfb6ZQtkMxYHpcyYo0OZFJ0qe7oaABw0vdNB7xFChz1erMgFnPSpqCAm1aPsAnT2GZ-2BO9IpbuAV43hA50uvoVGmeBYdW-2F2kYwE6-2FvlkH8HfFt8wo0cnNgwijRKdr4-2B8B5JMlhWKzCnUDOozyUc-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important"><span> </span>_______________________________________________<span class=""><br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></div></span></blockquote></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=pQw7h83fWt3LLbgkfL4TSUL0weaZnVFZxDe5GShw4uTMV-2BsplLYTZibm-2BsLvtzp-2BgRaOIn3oft1hUUGlFbJeQhcON1N6hwS8V2vrUZFvO9hUX4scxAVrewr-2FCWcGa3ItH6nmZ7Iz0PQmBisagUD6W8KyqJnfpKQ6h2hBeDq2pGj1P-2BCuH-2BueHEC27AoybyUutMmc-2B9mJS-2BV-2Biecf7pIbAQ-3D-3D" alt="" width="1" height="1" border="0" style="min-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">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>