Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type (#83)
From: Simon Peyton Jones <[email-masked]>
To: Joachim Breitner <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 17 Apr 2018 08:08:28 +0000
List-Id: Correspondence between the members of the GHC Steering Committe <ghc-steering-committee.haskell.org>

I think we all agree that we should collapse -XPolyKinds and -XTypeInType.  The only issue is what to do about *.  No solution is perfect: let's get this decided!

The status quo is terrible!

* With -XTypeInType,
    - '*' means Type iff '*' is imported from Data.Kind
    - '*' has no special meaning otherwise; that is, it's an
      ordinary infix operator, and is used as such in TypeLits
    - Ambiguity error if it is in scope two ways)

* Without -XTypeInType
    - '*' means Type iff it is used in a context that syntactically
      means "this is a kind"
    - '*' has no special meaning otherwise

That is, the meaning of '*' depends both on the extension flags -- and moreover on a flag whose primary purpose is quite separate -- AND depends (in some cases) on lexical scope or (in other cases) on syntactic context.  This is a ridiculous design.

The simplest thing to do is to say
  * The meaning of '*' is controlled by a flag, -XStarIsType, that has no
    other purpose
  * -XStarIsType is on by default.  (Perhaps: switched off by -XTypeOperators.)
  * 'Type' is exported by Data.Type (or whatever) and is always available
    as an alternative to '*'.
  * When -XStarIsType is on, we print '*' in error messages whenever possible.

That is simple and explicable.  Moreover the on-by-default rule means that most existing prams that use PolyKinds will continue to work unchanged.  In effect -XStarIsType is roughly the delta between -XPolyKinds and -XTypeInType.

Once that is in place we can think about future policy. For example

- Leave it alone
- Announce that -XStarIsType will move to off-by-default in a
  specified future GHC XX.YY,
  and emit deprecation messages for three previous releases

But let's get this done, one way or another.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  [email-masked]> On Behalf Of Joachim Breitner
|  Sent: 16 April 2018 18:46
|  To: [email-masked]
|  Subject: Re: [ghc-steering-committee] Proposal: Embrace Type in Type
|
|  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
|    [email-masked]
|    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C5dcaf0bd93bc4cd1728e08d5a43a722c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636595493286643160&sdata=HiboayTz2ffnt82UBzHb8%2FmrNMO4cm3O4iMI1FgYiuY%3D&reserved=0
_______________________________________________
ghc-steering-committee mailing list
[email-masked]
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee