Why are there no Show instances for internal types

Rahul Muttineni rahulmutt at gmail.com
Sat Mar 18 20:38:56 UTC 2017


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
>



-- 
Rahul Muttineni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170319/f17412da/attachment.html>


More information about the ghc-devs mailing list