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

[Simon Peyton Jones]

Thanks Iavor

  *   I strongly support collapsing TypeInType and PolyKinds.
     *   I can never remember the precise differences.
     *   Having the distinction carries no user benefit; it is grounded in history not user benefit
     *   …but maintaining the distinction has very significant costs in the compiler.


  *   I also support using Type instead of *.   Think of it like this: if were designing Haskell today, would we really pick a binary operator and use it as a nullary type constructor?  Surely not.  It’s a huge wart.  E.g.  If you write (a :: *->*) GHC gets confused because it thinks *->* is one lexeme.   And * is a jolly useful infix binary type constructor!!  (Or in type-level arithmetic.)

Yes, * is familiar to us old guys.  But you just get used to things.  If you want brevity, say type T = Type.  I think you’d adjust quickly.

I think we should just bit the bullet on this one.

Simon


From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Iavor Diatchki
Sent: 25 January 2018 21:45
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] Proposal: Embrace Type in Type

Hello,

I am the shepherd for pull request #83 "Embrace Type in Type" ( https://github.com/ghc-proposals/ghc-proposals/pull/83<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F83&data=02%7C01%7Csimonpj%40microsoft.com%7C1f034b5d72644d8d209008d5643cf50c%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636525135336888213&sdata=wwC%2BmVnVzPRX0luaGkC5g6deSb3qEd4jEWC%2BBg8TnNE%3D&reserved=0>), and so I'd like to hear your thoughts about the proposal.

In short, the proposal has two parts:
   1. Deprecate the use of `*` for the kind of inhabited Haskell types, and replace it with `Type`.
   2. Deprecate extension `TypeInType`, and move its functionality to extension `PolyKinds`.

At first I was quite skeptical about both of these, but after some thought I've realized that most of my concerns are not so much about Type in Type, but rather about the data promotion mechanism, and so I won't discuss them in this e-mail.

As such, I think I would be OK with part 2.  In particular, I like that when using TypeInType, one is explicit about kind parameters, as the implicit parameters of `PolyKinds` can be quite confusing.  Technically, being explicit about kind parameters is an orthogonal issue to mixing up types and kinds, but this is where we are at the moment, and I think `PolyKinds` is probably more useful with `TypeInType`.

Part 1 of the proposal is obviously just a syntactic thing, but I am a bit concerned about it.  In part because I actually tried for a while to use `Type` instead of `*`, and I found that the resulting kind signatures looked much more complicated.    Quite possibly this is because I am very used to using `*` and eventually I would adjust, but things just ended up being much longer.  It also seems unfortunate that this would break quite a lot of code, and obsolete a bunch of documentation and tutorials online.

So while I understand the reason for the proposal (the confusion between `*` the type function, and `*` the kind), I am not very keen on making this change.   The proposal also suggests another extension, `StarIsType`, and when enabled `*` will always refer to the kind, and never to the type function.  I am even less keen about this option, as I think it is better to pick a single notation and stick with it.

I'd love to hear what others think!

-Iavor




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