<div dir="ltr"><div>My vote would be to either keep `*` or stick with `Type` as originally intended.  I am not sure that the other alternatives are any better, as they are almost as long as `Type` and would require yet more special case explaining, for little readability value, I think.</div><div><br></div><div>Does anyone else have any input on either part of the proposal?</div><div><br></div><div>-Iavor</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div> </div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 26, 2018 at 10:14 AM Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">I (the proposer) also want to clarify that the proposal leaves some wiggle room about the deprecation of *:<div> - We could continue to support *-as-Type into perpetuity, as long as -XTypeOperators is not on.</div><div> - 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> - We could continue to support Unicode \bigstar (as we do today) as Type. This doesn't conflict with *-the-multiplication-operator.</div><div><br></div><div><div>I would love some guidance from the committee on the above points.</div></div><div><br></div><div>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><br></div><div>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><br></div><div>I'm sorry if adding this alternative late in the game is disruptive, but I thought it worthy of consideration.</div><div><br></div><div><div>Thanks,</div><div>Richard</div><div><br><blockquote type="cite"></blockquote></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div>On Jan 25, 2018, at 5:11 PM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:</div><br class="m_7994102950684194017Apple-interchange-newline"></blockquote></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div class="m_7994102950684194017WordSection1" 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"><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span>Thanks Iavor<u></u><u></u></span></div><ul type="disc" style="margin-bottom:0cm;margin-top:0cm"><li class="m_7994102950684194017MsoListParagraph" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span>I strongly support collapsing TypeInType and PolyKinds. <u></u><u></u></span><ul type="circle" style="margin-bottom:0cm;margin-top:0cm"><li class="m_7994102950684194017MsoListParagraph" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span>I can never remember the precise differences. <u></u><u></u></span></li><li class="m_7994102950684194017MsoListParagraph" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span>Having the distinction carries no user benefit; it is grounded in history not user benefit<u></u><u></u></span></li><li class="m_7994102950684194017MsoListParagraph" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span>…but maintaining the distinction has very significant costs in the compiler.<u></u><u></u></span></li></ul></li></ul><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><ul type="disc" style="margin-bottom:0cm;margin-top:0cm"><li class="m_7994102950684194017MsoListParagraph" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span>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.)<u></u><u></u></span></li></ul><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="margin:0cm 0cm 0.0001pt 36pt;font-size:11pt;font-family:Calibri,sans-serif"><span>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. <u></u><u></u></span></div><div style="margin:0cm 0cm 0.0001pt 36pt;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="margin:0cm 0cm 0.0001pt 36pt;font-size:11pt;font-family:Calibri,sans-serif"><span>I think we should just bit the bullet on this one.<u></u><u></u></span></div><div style="margin:0cm 0cm 0.0001pt 36pt;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="margin:0cm 0cm 0.0001pt 5.1pt;font-size:11pt;font-family:Calibri,sans-serif"><span>Simon<u></u><u></u></span></div><div style="margin:0cm 0cm 0.0001pt 36pt;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><a name="m_7994102950684194017__MailEndCompose"><span><u></u> <u></u></span></a></div><span></span><div style="border-style:none none none solid;border-left-width:1.5pt;border-left-color:blue;padding:0cm 0cm 0cm 4pt"><div><div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0cm 0cm"><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><b><span lang="EN-US">From:</span></b><span lang="EN-US"><span class="m_7994102950684194017Apple-converted-space"> </span>ghc-steering-committee [<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">mailto:ghc-steering-committee-bounces@haskell.org</a>]<span class="m_7994102950684194017Apple-converted-space"> </span><b>On Behalf Of<span class="m_7994102950684194017Apple-converted-space"> </span></b>Iavor Diatchki<br><b>Sent:</b><span class="m_7994102950684194017Apple-converted-space"> </span>25 January 2018 21:45<br><b>To:</b><span class="m_7994102950684194017Apple-converted-space"> </span><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br><b>Subject:</b><span class="m_7994102950684194017Apple-converted-space"> </span>[ghc-steering-committee] Proposal: Embrace Type in Type<u></u><u></u></span></div></div></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">Hello,<u></u><u></u></p><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><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="m_7994102950684194017Apple-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" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/83</a>), and so I'd like to hear your thoughts about the proposal.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">In short, the proposal has two parts:<u></u><u></u></p></div><div><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`.<u></u><u></u></p></div><div><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`.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><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.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><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`.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><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.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><br>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.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">I'd love to hear what others think!<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">-Iavor<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div></div></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><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;float:none;display:inline!important">_______________________________________________</span></div></blockquote></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><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"><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;float:none;display:inline!important">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"><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;float:none;display:inline!important"><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">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"><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;float:none;display:inline!important"><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a></span></div></blockquote></div></div></div></blockquote></div>