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 <[email protected]> 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 > > [email protected] > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
