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

[Iavor Diatchki]

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 at 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 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
> <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/20180129/99967846/attachment.html>