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

[Richard Eisenberg]

Hi Iavor,

See my answers below.

> On Apr 17, 2018, at 2:23 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> 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?

Not quite.

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.

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 *.

For point (2), the conditions are slightly different than what you write. They should be
 a. enables -XTypeOperators
 b. uses `*` in kind signatures
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.

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.

Richard


> 
> -Iavor
>        
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Apr 16, 2018 at 10:46 AM Joachim Breitner <mail at joachim-breitner.de <mailto: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 <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> 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/3adbe57d/attachment.html>