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

[Manuel M T Chakravarty]

I am 100% for Part 2 of the proposal.

Regarding Part 1, I am not keen on moving further from the Report, but then the original Haskell spec wasn’t written with the sort of type-level programming extensions in mind that we have now. Hence, it is probably better to have the short, sharp pain of a change, rather than carry the cruft with us forever.

However, I have to say, I am very intrigued with the alternative to the proposal that Richard mentioned in this thread, namely to use ”type”, not ”Type”. The more I think about it, the more I like this idea.

* It allows us to have ”type” (the kind) available at all times, which, I think, is justified, given its very special meaning and ubiquitous need for denoting kind signatures.

* I also think, it is good to distinguish it from other kind constructors as it is not at all like the others.

* Having a lower case first letter, in my view, does decrease the additional visual noise over ’*’ (that Iavor mentioned) a bit.

* I also don’t think there is much risk to confuse it with a type variable as syntax highlighting will mark it up as a keyword, not a variable.

* Finally, it means that

    type T = Bool

  adds another equality to ”type”, which is really nice.

Cheers,
Manuel

> Am 26.01.2018 um 08:45 schrieb Iavor Diatchki <iavor.diatchki at gmail.com>:
> 
> Hello,
> 
> I am the shepherd for pull request #83 "Embrace Type in Type" ( https://github.com/ghc-proposals/ghc-proposals/pull/83 <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
> 
> 
> 
> 
> _______________________________________________
> 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/20180202/717e2bde/attachment.html>