<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I am 100% for Part 2 of the proposal.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">* 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.</div><div class=""><br class=""></div><div class="">* I also think, it is good to distinguish it from other kind constructors as it is not at all like the others.</div><div class=""><br class=""></div><div class="">* Having a lower case first letter, in my view, does decrease the additional visual noise over ’*’ (that Iavor mentioned) a bit.</div><div class=""><br class=""></div><div class="">* 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.</div><div class=""><br class=""></div><div class="">* Finally, it means that</div><div class=""><br class=""></div><div class=""> type T = Bool</div><div class=""><br class=""></div><div class=""> adds another equality to ”type”, which is really nice.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Manuel<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Am 26.01.2018 um 08:45 schrieb Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" class="">iavor.diatchki@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello,<div class=""><br class=""></div><div class="">I am the shepherd for pull request #83 "Embrace Type in Type" ( <a href="https://github.com/ghc-proposals/ghc-proposals/pull/83" class="">https://github.com/ghc-proposals/ghc-proposals/pull/83</a>), and so I'd like to hear your thoughts about the proposal.</div><div class=""><br class=""></div><div class="">In short, the proposal has two parts:</div><div class=""> 1. Deprecate the use of `*` for the kind of inhabited Haskell types, and replace it with `Type`.</div><div class=""> 2. Deprecate extension `TypeInType`, and move its functionality to extension `PolyKinds`.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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`.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class="">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.</div><div class=""><br class=""></div><div class="">I'd love to hear what others think!</div><div class=""><br class=""></div><div class="">-Iavor</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></body></html>