<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 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><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" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span><div><div><div><br class="Apple-interchange-newline"><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">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 href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">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: +46-73-753 24 62<br>E-mail:<span class="Apple-converted-space"> </span><a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br><br><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="height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;"><span class="Apple-converted-space"> </span>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div></body></html>