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

[Richard Eisenberg]

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 at 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 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
> 
>  
> 
>  
> 
>  
> 
>  
> 
> _______________________________________________
> 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/20180126/a8776de6/attachment.html>