Opened 3 years ago

Closed 3 years ago

#12029 closed feature request (wontfix)

Notify user to import * from Data.Kind with TypeInType on

Reported by: Iceland_jack Owned by: johnleo
Priority: lowest Milestone:
Component: GHCi Version: 8.1
Keywords: TypeInType Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


With TypeInType asking for the kind of * gives the user a warning to import it

ghci> :set -XTypeInType 
ghci> :k *

<interactive>:1:1: error:
    Not in scope: type constructor or class ‘*’
    NB: With TypeInType, you must import * from Data.Kind

<interactive>:1:1: error:
    Illegal operator ‘*’ in type ‘*’
      Use TypeOperators to allow operators in types

<interactive>:1:1: error: Operator applied to too few arguments: *

Should a similar warning be issued when she asks for information on it

ghci> :i *
class Num a where
  (*) :: a -> a -> a
        -- Defined in ‘GHC.Num’
infixl 7 *

Change History (7)

comment:1 Changed 3 years ago by johnleo

The "NB" was added in this patch: I don't see a corresponding trac ticket. It seems there was some doubt as to whether this was the best course.

There are actually a number of inconsistent behaviors with * and which could be addressed. For one thing if you import * from Data.Kind you don't get also which might be confusing since one is supposed to be the Unicode version of the other, but maybe this is okay.

Another is that you do :set -fprint-unicode-syntax then :k displays kinds as whereas :i displays kinds as *.

The NB for * (it works the same way for ) only shows up if you have no other definition for * in the kind namespace. So for example if you define (with TypeOperators)

data (f * g) e = Inl1 (f e) | Inr1 (g e)
data (f ★ g) e = Inl2 (f e) | Inr2 (g e)

you will now get

ghci> :k (*)
(*) ∷ ∀ {k}. (k → ★) → (k → ★) → k → ★
ghci> :k (★)
(★) ∷ ∀ {k}. (k → ★) → (k → ★) → k → ★

with no mention of the missing kind * or . If you next import them you'll get an error for an ambiguous occurrence.

Also with no parens:

ghci> :k *
<interactive>:1:1: error: Operator applied to too few arguments: *

I suppose the NB was added to handle a very specific case in which a naive user doing nothing sophisticated was trying to find the kind of * and was surprised it didn't exist. Perhaps it would be equally surprising to find it not showing up with :i, but as this is more of a search over all uses I'd be inclined not to bother adding this special note. In addition I'd recommend dropping the NB change in 8.2 to make the behaviors consistent, since the requirement to import * from Data.Kind is clearly documented and people will have had time to absorb the change by then. However I'm happy to hear other opinions about either of these proposals.

Finally, since * and are both deprecated should we not be using Type from 8.2 onward? As in

ghci> :k (*)
(*) ∷ Type
Last edited 3 years ago by johnleo (previous) (diff)

comment:2 in reply to:  1 ; Changed 3 years ago by Iceland_jack

Replying to johnleo:

Finally, since * and are both deprecated should we not be using Type from 8.2 onward? As in

ghci> :k (*)
(*) ∷ Type

That is brought up in #12030

comment:3 in reply to:  2 Changed 3 years ago by johnleo

Replying to Iceland_jack:

Replying to johnleo: That is brought up in #12030

Ah, very good! I certainly agree.

comment:4 Changed 3 years ago by goldfire

Thanks, John, for looking into this.

  • * 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 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 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 changing the pretty-printer to use Type instead of *. This is not to be done lightly, however. There are several issues here:
    • 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 three releases.
    • 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 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 *.
  • -fprint-unicode-syntax should use the unicode star for as long as we use * in regular output. This should be regardless of context.
  • I like the NB. It's for naive users as John suggests. But it also frequently reminds me to import Data.Kind. Frankly, that's why I added it! Please keep it for several releases. See note about blog posts and textbooks, above.
  • * and the unicode star are just ordinary importable symbols with -XTypeInType. Nothing more, nothing less. There is no compiler-aware relationship between the two, other than the fact that both are synonyms for Type.
  • Iceland Jack: You started this ticket. Did you come by the reported infelicity (confusing behavior from :i *) "honestly"? By this, I mean were you actually confused by GHC's behavior such that you needed different output to make you not confused? Or did you just notice an inconsistency which is, well, infelicitous? I ask because the treatment of * in GHC 8 is very much a dirty hack. I think fixing this bug will make it dirtier. If GHC is truly being confusing, then perhaps this is worth it. But I'm not convinced that fixing this is worth it if we're just doing it for the sake of consistency. (Note: I'm not arguing that the current behavior is the best possible behavior!)

comment:5 Changed 3 years ago by johnleo

I have copied Richard's comments about deprecating * into I have also created for the work to fix display of * when unicode is set. I agree with Richard's arguments to not change the behavior of either :k * or :i * for now, and am closing this feature request. If Iceland Jack or anyone else feels very passionately about it, feel free to reopen with additional justification.

comment:6 Changed 3 years ago by johnleo

Owner: set to johnleo

comment:7 Changed 3 years ago by johnleo

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.