<div dir="ltr">OK, I guess we should just accept this. <div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 17, 2018 at 6:57 PM 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">Done.</div><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Apr 17, 2018, at 7:09 PM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:</div><br class="m_-1698266319421683755Apple-interchange-newline"><div><div class="m_-1698266319421683755WordSection1" 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>Would it be worth revising the proposal to incorporate the thinking in this thread, including the answers to Iavor’s questions?<u></u><u></u></span></div><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;font-size:11pt;font-family:Calibri,sans-serif"><span>Simon<u></u><u></u></span></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><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_-1698266319421683755Apple-converted-space"> </span>ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>><span class="m_-1698266319421683755Apple-converted-space"> </span><b>On Behalf Of<span class="m_-1698266319421683755Apple-converted-space"> </span></b>Richard Eisenberg<br><b>Sent:</b><span class="m_-1698266319421683755Apple-converted-space"> </span>17 April 2018 20:22<br><b>To:</b><span class="m_-1698266319421683755Apple-converted-space"> </span>Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>><br><b>Cc:</b><span class="m_-1698266319421683755Apple-converted-space"> </span><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>; Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>><br><b>Subject:</b><span class="m_-1698266319421683755Apple-converted-space"> </span>Re: [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 style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Hi Iavor,<u></u><u></u></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">See my answers below.<u></u><u></u></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><br><br><u></u><u></u></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">On Apr 17, 2018, at 2:23 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" style="color:purple;text-decoration:underline" target="_blank">iavor.diatchki@gmail.com</a>> wrote:<u></u><u></u></div></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Hello,<u></u><u></u></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">I have a couple of pragmatic questions:<u></u><u></u></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">1.  To "fix" my code so that it is compatible with this change I need to do the following:<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">    1. Whenever I have kind signatures mentioning `*`, replace `*` with `Type`<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">    2. Import `Data.Kind(Type)`<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">    3. Resolve conflicts involving existing datatypes named `Type`.<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">2. If my code has all of the properties below, then it will break as soon as this change is adopted, so I have to fix it in some way straight away:<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">     1. uses `*` is a binary type operator, and<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">     2. uses `*` in kind signatures, and<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">     3. uses the `PolyKinds` language extension.<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">3. If my code does not have the properties in (2) but uses `*` in kind signatures, it will continue to work for 2 GHC releases, but then it will break, so I should do (1) sometime before.<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Is my understanding correct?<u></u><u></u></div></div></div></div></div></blockquote><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Not quite.<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">First off, this proposal *does not* propose deprecating *. Earlier versions may have, but that's no longer the case. There is no concrete plan to remove * at any point in the future. Any movement to do so would be years in the future, I imagine.<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">In point (1), "compatible" is unclear. I think you mean "compatible forever" as opposed to "compatible today". The changes you suggest in (1) are what you would have to do if we ever decide to deprecate *.<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">For point (2), the conditions are slightly different than what you write. They should be<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> a. enables -XTypeOperators<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"> b. uses `*` in kind signatures<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Modules that have these features will have to make an immediate change. They could either do the changes under your point (1) or enable -XStarIsType.<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">The only part of this proposal that mentions something that will happen in 2 releases is that -XTypeOperators will stop implying -XNoStarIsType in two releases. That particular aspect of this is up for debate, of course.<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Richard<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><br><br><u></u><u></u></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div><div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">-Iavor<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">       <u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div></div></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" style="color:purple;text-decoration:underline" target="_blank">mail@joachim-breitner.de</a>> wrote:<u></u><u></u></div></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Hi,<br><br>Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:<br>> An alternative that hasn't been suggested so far is to have<br>> -XStarIsType control the pretty-printer as well as the parser. Simon<br>> PJ and I discussed this this morning, thinking it was a good idea.<br>> Upon further consideration, my preference would be to bite the bullet<br>> and just switch to printing Type always, but I'm not really against<br>> the print-*-with-XStarIsType idea.<br><br>I’m with Simon here. We have, I believe, precedence where error<br>messages are affected by the language extension in scope, so this might<br>satisfy the principle of least surprise, and also cause the least<br>contention among our users.<br><br>We can still apply this rule when `-XNoStarIsType`:<br><br>> One slightly separate question is what to print. The proposal<br>> currently suggests to print Type. There was concern in this thread<br>> that it would be printed fully-qualified, but I like Joachim's<br>> suggestion in the last known email in this thread to special-case<br>> printing of Type; even if it's not imported, it would print as Type,<br>> not Data.Kind.Type. (Unless some other Type were in scope.) It is<br>> also easy to teach GHC to print a bespoke warning when a user writes<br>> Type when it is out of scope, telling them to import Data.Kind.<br><br>The proposal currently does not state which modules export Type. I can<br>infer from the text that it is Data.Kind, but this could be made<br>explicit. Also, the proposal should state whether it is re-exported<br>from Prelude or not (I assume it is not).<br><br>Cheers,<br>Joachim<br><br>--<span class="m_-1698266319421683755Apple-converted-space"> </span><br>Joachim Breitner<br> <span class="m_-1698266319421683755Apple-converted-space"> </span><a href="mailto:mail@joachim-breitner.de" style="color:purple;text-decoration:underline" target="_blank">mail@joachim-breitner.de</a><br> <span class="m_-1698266319421683755Apple-converted-space"> </span><a href="http://www.joachim-breitner.de/" style="color:purple;text-decoration:underline" target="_blank">http://www.joachim-breitner.de/</a><br>_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" style="color:purple;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" style="color:purple;text-decoration:underline" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><u></u><u></u></div></blockquote></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" style="color:purple;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" style="color:purple;text-decoration:underline" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a></div></div></blockquote></div></div></div></div></div></blockquote></div><br></div></blockquote></div>