Hello,

I have a couple of pragmatic questions:

1.  To "fix" my code so that it is compatible with this change I need to do the following:
    1. Whenever I have kind signatures mentioning `*`, replace `*` with `Type`
    2. Import `Data.Kind(Type)`
    3. Resolve conflicts involving existing datatypes named `Type`.

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:
     1. uses `*` is a binary type operator, and
     2. uses `*` in kind signatures, and
     3. uses the `PolyKinds` language extension.

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.

Is my understanding correct?

-Iavor
       








On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <mail@joachim-breitner.de> wrote:
Hi,

Am Montag, den 16.04.2018, 11:55 -0400 schrieb Richard Eisenberg:
> An alternative that hasn't been suggested so far is to have
> -XStarIsType control the pretty-printer as well as the parser. Simon
> PJ and I discussed this this morning, thinking it was a good idea.
> Upon further consideration, my preference would be to bite the bullet
> and just switch to printing Type always, but I'm not really against
> the print-*-with-XStarIsType idea.

I’m with Simon here. We have, I believe, precedence where error
messages are affected by the language extension in scope, so this might
satisfy the principle of least surprise, and also cause the least
contention among our users.

We can still apply this rule when `-XNoStarIsType`:

> One slightly separate question is what to print. The proposal
> currently suggests to print Type. There was concern in this thread
> that it would be printed fully-qualified, but I like Joachim's
> suggestion in the last known email in this thread to special-case
> printing of Type; even if it's not imported, it would print as Type,
> not Data.Kind.Type. (Unless some other Type were in scope.) It is
> also easy to teach GHC to print a bespoke warning when a user writes
> Type when it is out of scope, telling them to import Data.Kind.

The proposal currently does not state which modules export Type. I can
infer from the text that it is Data.Kind, but this could be made
explicit. Also, the proposal should state whether it is re-exported
from Prelude or not (I assume it is not).

Cheers,
Joachim

--
Joachim Breitner
  mail@joachim-breitner.de
  http://www.joachim-breitner.de/
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee