<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I (the proposer) also want to clarify that the proposal leaves some wiggle room about the deprecation of *:<div class=""> - We could continue to support *-as-Type into perpetuity, as long as -XTypeOperators is not on.</div><div class=""> - We could continue to print * in error messages, perhaps depending on various extensions. Or perhaps we have a -fprint-star-for-type or some such, which would perhaps be used by instructors of courses that use materials mentioning *.</div><div class=""> - We could continue to support Unicode \bigstar (as we do today) as Type. This doesn't conflict with *-the-multiplication-operator.</div><div class=""><br class=""></div><div class=""><div class="">I would love some guidance from the committee on the above points.</div></div><div class=""><br class=""></div><div class="">Lastly, the proposal does not include any plans for full removal of *, as it will leave GHC in a state where supporting *-as-type (with -XStarIsType) is not burdensome.</div><div class=""><br class=""></div><div class="">One final alternative (just added to the proposal, as I had forgotten about it previously) that may be appealing is to use "type" to mean "Type". Because "type" is a keyword, there are no scoping issues, and so it can be always in scope, making the transition from * easier.</div><div class=""><br class=""></div><div class="">I'm sorry if adding this alternative late in the game is disruptive, but I thought it worthy of consideration.</div><div class=""><br class=""></div><div class=""><div>Thanks,</div><div>Richard</div><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 25, 2018, at 5:11 PM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" class="">simonpj@microsoft.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Thanks Iavor<o:p class=""></o:p></span></div><ul type="disc" style="margin-bottom: 0cm; margin-top: 0cm;" class=""><li class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">I strongly support collapsing TypeInType and PolyKinds. <o:p class=""></o:p></span><ul type="circle" style="margin-bottom: 0cm; margin-top: 0cm;" class=""><li class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">I can never remember the precise differences. <o:p class=""></o:p></span></li><li class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">Having the distinction carries no user benefit; it is grounded in history not user benefit<o:p class=""></o:p></span></li><li class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">…but maintaining the distinction has very significant costs in the compiler.<o:p class=""></o:p></span></li></ul></li></ul><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><ul type="disc" style="margin-bottom: 0cm; margin-top: 0cm;" class=""><li class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">I also support using Type instead of *.   Think of it like this: if were designing Haskell today, would we really pick a binary operator and use it as a nullary type constructor?  Surely not.  It’s a huge wart.  E.g.  If you write (a :: *->*) GHC gets confused because it thinks *->* is one lexeme.   And * is a jolly useful infix binary type constructor!!  (Or in type-level arithmetic.)<o:p class=""></o:p></span></li></ul><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Yes, * is familiar to us old guys.  But you just get used to things.  If you want brevity, say type T = Type.  I think you’d adjust quickly. <o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">I think we should just bit the bullet on this one.<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt 5.1pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Simon<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><a name="_MailEndCompose" class=""><span class=""><o:p class=""> </o:p></span></a></div><span class=""></span><div style="border-style: none none none solid; border-left-width: 1.5pt; border-left-color: blue; padding: 0cm 0cm 0cm 4pt;" class=""><div class=""><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(225, 225, 225); padding: 3pt 0cm 0cm;" class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span lang="EN-US" class="">From:</span></b><span lang="EN-US" class=""><span class="Apple-converted-space"> </span>ghc-steering-committee [<a href="mailto:ghc-steering-committee-bounces@haskell.org" class="">mailto:ghc-steering-committee-bounces@haskell.org</a>]<span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>Iavor Diatchki<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>25 January 2018 21:45<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>[ghc-steering-committee] Proposal: Embrace Type in Type<o:p class=""></o:p></span></div></div></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">Hello,<o:p class=""></o:p></p><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">I am the shepherd for pull request #83 "Embrace Type in Type" (<span class="Apple-converted-space"> </span><a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F83&data=02%7C01%7Csimonpj%40microsoft.com%7C1f034b5d72644d8d209008d5643cf50c%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636525135336888213&sdata=wwC%2BmVnVzPRX0luaGkC5g6deSb3qEd4jEWC%2BBg8TnNE%3D&reserved=0" style="color: purple; text-decoration: underline;" class="">https://github.com/ghc-proposals/ghc-proposals/pull/83</a>), and so I'd like to hear your thoughts about the proposal.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">In short, the proposal has two parts:<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">   1. Deprecate the use of `*` for the kind of inhabited Haskell types, and replace it with `Type`.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">   2. Deprecate extension `TypeInType`, and move its functionality to extension `PolyKinds`.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">At first I was quite skeptical about both of these, but after some thought I've realized that most of my concerns are not so much about Type in Type, but rather about the data promotion mechanism, and so I won't discuss them in this e-mail.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">As such, I think I would be OK with part 2.  In particular, I like that when using TypeInType, one is explicit about kind parameters, as the implicit parameters of `PolyKinds` can be quite confusing.  Technically, being explicit about kind parameters is an orthogonal issue to mixing up types and kinds, but this is where we are at the moment, and I think `PolyKinds` is probably more useful with `TypeInType`.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">Part 1 of the proposal is obviously just a syntactic thing, but I am a bit concerned about it.  In part because I actually tried for a while to use `Type` instead of `*`, and I found that the resulting kind signatures looked much more complicated.    Quite possibly this is because I am very used to using `*` and eventually I would adjust, but things just ended up being much longer.  It also seems unfortunate that this would break quite a lot of code, and obsolete a bunch of documentation and tutorials online.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><br class="">So while I understand the reason for the proposal (the confusion between `*` the type function, and `*` the kind), I am not very keen on making this change.   The proposal also suggests another extension, `StarIsType`, and when enabled `*` will always refer to the kind, and never to the type function.  I am even less keen about this option, as I think it is better to pick a single notation and stick with it.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">I'd love to hear what others think!<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">-Iavor<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div></div></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">ghc-steering-committee mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a></span></div></blockquote></div><br class=""></div></body></html>