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

[Iavor Diatchki]

OK, I guess we should just accept this.



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

> Done.
>
>
> On Apr 17, 2018, at 7:09 PM, Simon Peyton Jones <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
> > *On Behalf Of *Richard Eisenberg
> *Sent:* 17 April 2018 20:22
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner <
> 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>
> 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> 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
>
> _______________________________________________
> 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/20180425/fc7d9926/attachment-0001.html>