<div dir="ltr">Hello,<div><br></div><div>I have a couple of pragmatic questions:<br><div><br></div><div>1. To "fix" my code so that it is compatible with this change I need to do the following:</div><div> 1. Whenever I have kind signatures mentioning `*`, replace `*` with `Type`<br></div><div> 2. Import `Data.Kind(Type)`</div><div> 3. Resolve conflicts involving existing datatypes named `Type`.</div><div><br></div><div>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:</div><div> 1. uses `*` is a binary type operator, and</div><div> 2. uses `*` in kind signatures, and</div><div> 3. uses the `PolyKinds` language extension.</div><div><br></div><div>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.</div><div><br></div><div>Is my understanding correct?</div><div><br></div><div>-Iavor</div><div> </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>