<div dir="ltr"><div>There&#39;s a lot of passionate Swift people here, it&#39;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&#39;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&#39;s going to be niche. However, DSLs in general are applicable to most apps, so perhaps there&#39;s something in that.</div><div><br></div>I think Krzysztof Siejkowski&#39;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&#39;m biased)</li></ul><div>Likewise there&#39;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&#39;re testing frameworks, their implementation DSL could really benefit from HKTs last time I looked at it. Likewise, I&#39;m not 100% sure but HKTs may be the building blocks upon which Swift&#39;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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</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&#39;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&#39;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&#39;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&#39;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&lt;T&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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&#39;m not sure I follow? Are you suggesting that having HKTs at all will encourage Swift programmers to use bad naming conventions? I don&#39;t think the two are related unless you&#39;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>