[ghc-steering-committee] Proposal: Embrace Type in Type

[Iavor Diatchki]

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 at 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180417/13b1e8a1/attachment.html>