[GHC] #15871: Revamp -fprint-explicit-kinds

[GHC]

#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