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

Wed Apr 25 07:33:44 UTC 2018

You sound reluctant, Iavor.  ?

The point of the process is to get broad consensus for changes, and to debug them.  It is not to allow vocal people like Richard and me to push through changes that others think are misguided.

Or maybe I’m over-interpreting your short utterance 😊.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 25 April 2018 01:21
To: Richard Eisenberg <rae at cs.brynmawr.edu>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type

OK, I guess we should just accept this.

On Tue, Apr 17, 2018 at 6:57 PM Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
Done.

On Apr 17, 2018, at 7:09 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

Would it be worth revising the proposal to incorporate the thinking in this thread, including the answers to Iavor’s questions?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Richard Eisenberg
Sent: 17 April 2018 20:22
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>; Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type

Hi Iavor,

See my answers below.

On Apr 17, 2018, at 2:23 PM, Iavor Diatchki <iavor.diatchki at gmail.com<mailto: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/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc3fbc3ccb9a34e49a2d808d5aa42671e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636602124533998677&sdata=jHw8yU8qzlu2KphFVYPy%2BabkbsbYmYwfzj529S8SIrI%3D&reserved=0>
_______________________________________________
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
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180425/4c32b17a/attachment-0001.html>