My vote would be to either keep `*` or stick with `Type` as originally intended.  I am not sure that the other alternatives are any better, as they are almost as long as `Type` and would require yet more special case explaining, for little readability value, I think.

Does anyone else have any input on either part of the proposal?

-Iavor







 

On Fri, Jan 26, 2018 at 10:14 AM Richard Eisenberg <rae@cs.brynmawr.edu> wrote:
I (the proposer) also want to clarify that the proposal leaves some wiggle room about the deprecation of *:
 - We could continue to support *-as-Type into perpetuity, as long as -XTypeOperators is not on.
 - We could continue to print * in error messages, perhaps depending on various extensions. Or perhaps we have a -fprint-star-for-type or some such, which would perhaps be used by instructors of courses that use materials mentioning *.
 - We could continue to support Unicode \bigstar (as we do today) as Type. This doesn't conflict with *-the-multiplication-operator.

I would love some guidance from the committee on the above points.

Lastly, the proposal does not include any plans for full removal of *, as it will leave GHC in a state where supporting *-as-type (with -XStarIsType) is not burdensome.

One final alternative (just added to the proposal, as I had forgotten about it previously) that may be appealing is to use "type" to mean "Type". Because "type" is a keyword, there are no scoping issues, and so it can be always in scope, making the transition from * easier.

I'm sorry if adding this alternative late in the game is disruptive, but I thought it worthy of consideration.

Thanks,
Richard

On Jan 25, 2018, at 5:11 PM, Simon Peyton Jones <simonpj@microsoft.com> wrote:

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@haskell.org] On Behalf Of Iavor Diatchki
Sent: 25 January 2018 21:45
To: ghc-steering-committee@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), 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

 

 

 

 

_______________________________________________