Why are there no Show instances for internal types

[Edward Z. Yang]

Hi Rahul,

This ticket may be of interest:

https://ghc.haskell.org/trac/ghc/ticket/10143

Edward

Excerpts from Rahul Muttineni's message of 2017-03-19 02:08:56 +0530:
> I think another way to go about this problem is to figure out an
> alternative to baking in DynFlags to SDocContext (which I feel is the core
> problem here). The only use of those DynFlags is via sdocWithDynFlags and
> 94 call sites use them.
> 
> - In the frontend, it's used to check for the presence of the flag (like
> suppress module prefixes, etc.)
> - In the code generator, it's used to get the word size, endianness, and
> other platform specific stuff for platform-specific printing.
> - Backpack-related stuff needed to get the package state
>   - Used in exactly 2 cases: Outputable instances for ComponentId and
> InstalledUnitId
> 
> From what I observed with the majority of use cases, sdocWithDynFlags is
> used to obviate the need for passing dflags to various ppr* functions,
> which is a good idea since without it, we'd probably have to pass around
> DynFlags to a whole lot more pure functions throughout the codebase.
> 
> So as others have said, Show instances are just not practical because
> printing many of the GHC types is highly dependent on the platform and what
> flags GHC was invoked with.
> 
> There are three solutions here:
> 1.) Figure out a subset of DynFlags (flags, platform details, package
> state) and only allow those inside of SDocContext and extend SDocContext as
>      new use cases come up. This is probably not practical as it would
> require sweeping changes.
> 2.) Provide a stock set of DynFlags for the purpose of printing with
> Outputable. It's easy to do for flags and platform details, but tricky to
> do for package state. This seems to be the most reasonable solution if some
> sane substitute for package state can be used.
> 
> Syd, can you tell us what kind of things you were trying to print out? You
> can try to pass in unsafeGlobalDynFlags but it may not be what you want. It
> gets written to on the initialisation of the GHC monad and after the
> command line options are parsed (so everything will be properly initialised
> except for package state).
> 
> Hope that helps,
> Rahul
> 
> On Sun, Mar 19, 2017 at 1:14 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > We can't add Show instances for these types because many types
> > below them, e.g., Type, are cyclic, and would result in infinite
> > output.
> >
> > Perhaps we can add a new type class which a) faithfully represents
> > the Haskell syntax, but b) can deal with cyclic data.  I think that's
> > something people would like (extra compilation time not withstanding).
> > But it sounds annoying to do since the deriving mechanism is not going
> > to help you.
> >
> > Edward
> >
> > Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> > > Dear GHC Devs,
> > >
> > > I am trying to use GHC as a library but I'm having a lot of trouble with
> > > understanding what everything means.
> > > Up to now, I have been able to figure out what to do by reading the
> > > sources, but it ocured to me that much of my struggles could have been
> > > mitigated if the relevant types had Show instances.
> > >
> > > I am specifically talking about the types concerning type checking.
> > > TypecheckedModule and everything below that.
> > > I am aware that most of the types have an Outputable instance, but
> > > there are two problems with that:
> > >
> > > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> > > - These instances are not intended to show the internal structure of a
> > >   value, but rather a 'human readable' representation of a value.
> > >
> > > My questions for you:
> > >
> > > - Is there a reason that there are no derived 'Show' instances for most
> > >   types?
> > > - Would you accept a diff that adds these?
> > >
> > > Thank you for your time.
> > >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>