<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="">Hi Iavor,<div class=""><br class=""></div><div class="">See my answers below.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 17, 2018, at 2:23 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" class="">iavor.diatchki@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello,<div class=""><br class=""></div><div class="">I have a couple of pragmatic questions:<br class=""><div class=""><br class=""></div><div class="">1. To "fix" my code so that it is compatible with this change I need to do the following:</div><div class=""> 1. Whenever I have kind signatures mentioning `*`, replace `*` with `Type`<br class=""></div><div class=""> 2. Import `Data.Kind(Type)`</div><div class=""> 3. Resolve conflicts involving existing datatypes named `Type`.</div><div class=""><br class=""></div><div class="">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 class=""> 1. uses `*` is a binary type operator, and</div><div class=""> 2. uses `*` in kind signatures, and</div><div class=""> 3. uses the `PolyKinds` language extension.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Is my understanding correct?</div></div></div></div></blockquote><div><br class=""></div><div>Not quite.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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 *.</div><div><br class=""></div><div>For point (2), the conditions are slightly different than what you write. They should be</div><div> a. enables -XTypeOperators</div><div> b. uses `*` in kind signatures</div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Richard</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">-Iavor</div><div class=""> </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<br class="">
Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:<br class="">
> An alternative that hasn't been suggested so far is to have<br class="">
> -XStarIsType control the pretty-printer as well as the parser. Simon<br class="">
> PJ and I discussed this this morning, thinking it was a good idea.<br class="">
> Upon further consideration, my preference would be to bite the bullet<br class="">
> and just switch to printing Type always, but I'm not really against<br class="">
> the print-*-with-XStarIsType idea.<br class="">
<br class="">
I’m with Simon here. We have, I believe, precedence where error<br class="">
messages are affected by the language extension in scope, so this might<br class="">
satisfy the principle of least surprise, and also cause the least<br class="">
contention among our users.<br class="">
<br class="">
We can still apply this rule when `-XNoStarIsType`:<br class="">
<br class="">
> One slightly separate question is what to print. The proposal<br class="">
> currently suggests to print Type. There was concern in this thread<br class="">
> that it would be printed fully-qualified, but I like Joachim's<br class="">
> suggestion in the last known email in this thread to special-case<br class="">
> printing of Type; even if it's not imported, it would print as Type,<br class="">
> not Data.Kind.Type. (Unless some other Type were in scope.) It is<br class="">
> also easy to teach GHC to print a bespoke warning when a user writes<br class="">
> Type when it is out of scope, telling them to import Data.Kind.<br class="">
<br class="">
The proposal currently does not state which modules export Type. I can<br class="">
infer from the text that it is Data.Kind, but this could be made<br class="">
explicit. Also, the proposal should state whether it is re-exported<br class="">
from Prelude or not (I assume it is not).<br class="">
<br class="">
Cheers,<br class="">
Joachim<br class="">
<br class="">
-- <br class="">
Joachim Breitner<br class="">
<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a><br class="">
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank" class="">http://www.joachim-breitner.de/</a><br class="">
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></body></html>