#15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: 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 RyanGlScott): I'd be willing to give this a shot (assuming that no one else is working on this at the moment). Design question: in order to be able to tell when we should print `@(...)` versus `@{...}`, we'll need to store whether an argument is specified or inferred. Unfortunately, the data structure that we currently use to pretty-print type applications, `IfaceAppArgs`, is not suited for this task in its current design: {{{#!hs data IfaceAppArgs = IA_Nil | IA_Vis IfaceType IfaceAppArgs | IA_Invis IfaceType IfaceAppArgs }}} `IfaceAppArgs` lets you distinguish between visible and invisible arguments, but it doesn't give you the ability to tell whether an invisible argument is specified or inferred. Here are various solutions that I've considered that would address this: 1. Add an `ArgFlag` field to `IA_Invis`. This would give you the ability to tell whether an invisible thing is specified or inferred without much additional fuss. The downside is that there's a bit of an impedance mismatch since `ArgFlag` also has the `Required` constructor, but an inferred argument can never be required. 2. Create a custom data type for `IA_Invis`'s purposes. Something like: {{{#!hs data IfaceInvisibility = II_Inferred | II_Specified }}} This solves the impedance mismatch, at the expense of having yet another data type to represent visibility. 3. Change `IfaceAppArgs` itself. Instead of having separate `IA_Vis` and `IA_Invis` constructors, combine them into a single `IA_Arg` constructor: {{{#!hs data IfaceAppArgs = IA_Nil | IA_Arg IfaceType ArgFlag IfaceAppArgs }}} Today's `IA_Vis` would correspond to a `Required` `IA_Arg`, and today's `IA_Invis` would correspond to a `Specified`/`Inferred` `IA_Arg`. I'm inclined to go with option 3, but I'll wait until I hear others' opinions on this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15871#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: 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 simonpj): I vote for (3) too. Much nicer! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15871#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5314 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f5d2083807a03c57f194fcc3a7baf82e34aad524/ghc" f5d2083/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f5d2083807a03c57f194fcc3a7baf82e34aad524" Overhaul -fprint-explicit-kinds to use VKA This patch changes the behavior of `-fprint-explicit-kinds` so that it displays kind argument using visible kind application. In other words, the flag now: 1. Prints instantiations of specified variables with `@(...)`. 2. Prints instantiations of inferred variables with `@{...}`. In addition, this patch removes the `Use -fprint-explicit-kinds to see the kind arguments` error message that often arises when a type mismatch occurs due to different kinds. Instead, whenever there is a kind mismatch, we now enable the `-fprint-explicit-kinds` flag locally to help cue to the programmer where the error lies. (See `Note [Kind arguments in error messages]` in `TcErrors`.) As a result, these funny `@{...}` things can now appear to the user even without turning on the `-fprint-explicit-kinds` flag explicitly, so I took the liberty of documenting them in the users' guide. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15871 Differential Revision: https://phabricator.haskell.org/D5314 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15871#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler