[GHC] #12030: GHCi Proposal: Display (Data.Kind.)Type instead of *
#12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is premature but what the darn, {{{
:kind Maybe Maybe :: Type -> Type :kind StateT StateT :: Type -> (Type -> Type) -> Type -> Type :kind Eq Eq :: Type -> Constraint
:info Functor class Functor (f :: Type -> Type) where ... }}}
`*` throws students off and makes it seem scarier than it is. Symbols are harder to search for in general and to understand without documentation, `Type` on the other hand is descriptive. There are valid arguments against displaying `Type`: 1. It's a recent feature subject to change. 2. Although symbols are more difficult to search for, `*` is established in educational materials, logs, blogs and questions. 3. By default `Type` is not in scope so a user cannot ask for information in GHCi. `*` is established and searching for “Haskell asterisk” yields a lot resources but [https://support.google.com/websearch/answer/2466433?hl=en ‘*’ is also a wildcard] in Google and ignored by GitHub. With time `Type` would be a good search term but currently it's chicken-and-the-egg. Previous versions of GHCi error on `:kind *` and `:info *` only shows multiplication so that wouldn't be a huge difference but we can qualify by default: {{{
:kind Maybe Maybe :: Data.Kind.Type -> Data.Kind.Type :kind StateT StateT :: Data.Kind.Type -> (Data.Kind.Type -> Data.Kind.Type) -> Data.Kind.Type -> Data.Kind.Type :kind Eq Eq :: Data.Kind.Type -> Constraint
:info Functor class Functor (f :: Data.Kind.Type -> Data.Kind.Type) where ... }}}
or display `*` normally and only when `TypeInType` is set do we display `Type`. I don't love it (and love `GHC.Types.Type` slightly less) but there is a precedent for unqualified names, browsing the Prelude for example: {{{#!hs ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b undefined :: forall (r :: GHC.Types.RuntimeRep) (a :: TYPE r). GHC.Stack.Types.HasCallStack => a }}} __If__ the consensus is that this will happen sometime down the line consider that each passing release means many more books and blog posts get written using `*`. I wasn't planning on resulting to scare tactics but [https://www.peoria.com/spaw/spawimages/members/member60763/shoot_this_dog.jp... here we are]... ---- If needed a migration plan can be drafted like the Semigroup/FTP/AMP/BBP/MonadFail/expanding Float/... proposals, possibly culminating in `Type` fully replacing `*` and being imported by default. I'm sure there are some further reaching consequences to this and better arguments against. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12030 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -16,2 +16,2 @@ - `*` throws students off and makes it seem scarier than it is. Symbols are - harder to search for in general and to understand without documentation, + `*` throws students off in my experience, makes it seem scarier than it + is. Symbols are harder to search for and understand without documentation, @@ -20,1 +20,1 @@ - There are valid arguments against displaying `Type`: + There are arguments against: @@ -22,5 +22,4 @@ - 1. It's a recent feature subject to change. - 2. Although symbols are more difficult to search for, `*` is established - in educational materials, logs, blogs and questions. - 3. By default `Type` is not in scope so a user cannot ask for information - in GHCi. + 1. It's a recent feature that is subject to change. + 2. `*` is established in questions online, educational material, logs and + blogs. + 3. `Type` is not in scope by default: user cannot query GHCi. New description: This is premature but what the darn, {{{
:kind Maybe Maybe :: Type -> Type :kind StateT StateT :: Type -> (Type -> Type) -> Type -> Type :kind Eq Eq :: Type -> Constraint
:info Functor class Functor (f :: Type -> Type) where ... }}}
`*` throws students off in my experience, makes it seem scarier than it is. Symbols are harder to search for and understand without documentation, `Type` on the other hand is descriptive. There are arguments against: 1. It's a recent feature that is subject to change. 2. `*` is established in questions online, educational material, logs and blogs. 3. `Type` is not in scope by default: user cannot query GHCi. `*` is established and searching for “Haskell asterisk” yields a lot resources but [https://support.google.com/websearch/answer/2466433?hl=en ‘*’ is also a wildcard] in Google and ignored by GitHub. With time `Type` would be a good search term but currently it's chicken-and-the-egg. Previous versions of GHCi error on `:kind *` and `:info *` only shows multiplication so that wouldn't be a huge difference but we can qualify by default: {{{
:kind Maybe Maybe :: Data.Kind.Type -> Data.Kind.Type :kind StateT StateT :: Data.Kind.Type -> (Data.Kind.Type -> Data.Kind.Type) -> Data.Kind.Type -> Data.Kind.Type :kind Eq Eq :: Data.Kind.Type -> Constraint
:info Functor class Functor (f :: Data.Kind.Type -> Data.Kind.Type) where ... }}}
or display `*` normally and only when `TypeInType` is set do we display `Type`. I don't love it (and love `GHC.Types.Type` slightly less) but there is a precedent for unqualified names, browsing the Prelude for example: {{{#!hs ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b undefined :: forall (r :: GHC.Types.RuntimeRep) (a :: TYPE r). GHC.Stack.Types.HasCallStack => a }}} __If__ the consensus is that this will happen sometime down the line consider that each passing release means many more books and blog posts get written using `*`. I wasn't planning on resulting to scare tactics but [https://www.peoria.com/spaw/spawimages/members/member60763/shoot_this_dog.jp... here we are]... ---- If needed a migration plan can be drafted like the Semigroup/FTP/AMP/BBP/MonadFail/expanding Float/... proposals, possibly culminating in `Type` fully replacing `*` and being imported by default. I'm sure there are some further reaching consequences to this and better arguments against. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12030#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
* `*` is not (yet) deprecated. While I did work with the larger community to come up with the name `Type`, I don't recall getting specific support for deprecating `*`. I do think this is a good direction of
#12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): Comments by Richard Eisenberg (goldfire), copied from [https://ghc.haskell.org/trac/ghc/ticket/12029]: travel, but I don't think we should do this without more of a community mandate.
* There are no kind synonyms in GHC 7.10 or below. Thus, according to
the [https://prime.haskell.org/wiki/Libraries/3-Release-Policy three- release policy] (which isn't a formal operating policy of GHC, I don't think) we should wait until 8.4 before starting to deprecate `*`.
* If the community agrees on moving away from `*`, we could add warnings
about `*` to `-Wcompat`.
* If the community agrees on moving away from `*`, we could also start
- Blogs, textbooks, etc., have used `*` for a long time. Furthermore, kinds are hard for newcomers to understand. Changing GHC's output will make this harder. - Until 8.4 comes out, it will be hard for a library author to discover that `*` is the right way to spell `Type` that is compatible with
- The use of `*` as a kind is enshrined in the Haskell Reports. These Reports do not specify the error/warning behavior of a compiler, and so
changing the pretty-printer to use `Type` instead of `*`. This is not to be done lightly, however. There are several issues here: three releases. this change is not exactly a deviation from a standard. But it continues to make GHC seem as if it's drifting away from the standard with little remorse.
* I personally think we should wait at least 5-6 years before formally
disposing of `*`. I will create a proposal in [https://github.com/ghc-proposals/ghc- proposals] in the near future to start a conversation. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12030#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: johnleo Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * owner: => johnleo -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12030#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: johnleo Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.6.1 Comment: My understanding is that the `-XNoStarIsType` extension gives you exactly what you seek here, since that displays `*` as `Type` in GHCi: {{{ GHCi, version 8.6.0.20180714: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :kind Int Int :: * λ> :set -XNoStarIsType λ> :kind Int Int :: Type }}} As such, I'm opting to close this. (There's still an [https://github.com/ghc-proposals/ghc-proposals/pull/143 ongoing discussion] about whether `-XNoStarIsType` should be the default, but that's a separate matter.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12030#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC