Revamp -fprint-explicit-kinds

With the imminent #12045 (closed), we will have type application in kinds. This ticket tracks mirroring this new behavior in the pretty-printer.

To wit, when -fprint-explicit-kinds is enabled, we should

1. Print instantiations of specified variables like @....
2. Print instantiations of inferred variables like @{...}.

Examples:

data Proxy (a :: k) = Proxy
 -- Then, `Proxy Int` would be printed as `Proxy @Type Int` with -fprint-explicit-kinds

data Proxy2 a = Proxy2
 -- Then, `Proxy2 Int` would be printed as `Proxy2 @{Type} Int` with -fprint-explicit-kinds

In addition, sometimes error messages suggest enabling -fprint-explicit-kinds. Instead of doing this, we should just locally enable the flag. The existence of the @ prefixes will alert the reader that these are not type arguments. (Without the @ syntax, locally and silently enabling -fprint-explicit-kinds would be very confusing.)

Trac metadata

Trac field	Value
Version	8.6.2
Type	Task
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Ttask Trac import labels

Yes! Let's do it!

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:

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:

data IfaceInvisibility
  = II_Inferred
  | II_Specified   

This solves the impedance mismatch, at the expense of having yet another data type to represent visibility.

1. Change IfaceAppArgs itself. Instead of having separate IA_Vis and IA_Invis constructors, combine them into a single IA_Arg constructor:

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.

I vote for (3) in ticket:15871#comment:163331. I think that's a general improvement over the status quo, regardless of the behavior change proposed in this ticket.

Is it ever the case that we print invisible arguments in terms? We should perhaps mirror the treatment in types in terms, as well. But maybe that's better in a separate ticket.

I vote for (3) too. Much nicer!

changed milestone to %8.8.1

Trac metadata

Trac field	Value
Differential revisions	- → D5314

mentioned in commit f5d20838

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

added Pnormal label