<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I am actually +1 on adding HKTs eventually. I would really like to see them in Swift.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I also think fleshing out the existing generics features is a much more immediate concern. It's pretty clear we won't see every generics feature we can imagine in Swift 3 so we need to choose. I would prefer to see the existing features fully fleshed out and limitations removed before we start introducing more sophisticated features into the type system.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Collecting a list of libraries you think might benefit from HKTs is a good start for providing more concrete motivation in the context of Swift. I think a good next step would be to imagine how those libraries might look different if Swift had HKTs. The API should ideally be comfortable for users whether they understand HKTs or not (or even know they exist). </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">How would the implementations be better and the interfaces more composable and / or safer? For the DSL examples, how would the HKT approach be superior to other approaches? Answering these questions with hypothetical but concrete examples will do a lot to change the conversation and maybe also increase the priority.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Matthew</div><div id="AppleMailSignature"><br>Sent from my iPad</div><div><br>On Dec 17, 2015, at 9:40 AM, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><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>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAfTof3ZGsroWjVzTRlOKptva-2BNu44wpc4jVv7sDdwbMLkv1wt5MdFEf26IXkasLXTQiHwF1hQKtkjDHyKtxHQ3dprtcN-2FdA8W2DLn7qDaFb0QCbdQGgwXk4SCKHPzVnf0-2BG71OMw-2B-2FkzAUc2w2Syx5ToDL-2FgU-2BsWS1Gj8y2cvkgVsaFZcHPd2Qbqs2CfxO2KNY-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;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>