Re: Why are there no Show instances for internal types

Hi, Am Montag, den 20.03.2017, 12:51 + schrieb Simon Peyton Jones via ghc-devs: > Show and Outputable have very different goals though. > > Really? What's wrong with using Outputable, plus, as Joachim says,  > > showSDocUnsafe . ppr :: Outputable a => a -> String > > Maybe you want

RE: Why are there no Show instances for internal types

| > >- Is there a reason that there are no derived 'Show' instances for | > >most types? | > | > As Richard mentioned, we don't derive Show due to code size and | compilation time concerns. | > Show in particular is rather expensive to derive and seeing as we | already have Outputable I don't it

Re: Why are there no Show instances for internal types

Tom Sydney Kerckhove writes: > On 19-03-17 02:08:56, Rahul Muttineni wrote: >> Syd, can you tell us what kind of things you were trying to print out? > > Maybe I wasn't very clear. > I'm trying to visualise the internal structure of some of the > typechecker's output. >

Re: Why are there no Show instances for internal types

On 18-03-17 16:13:52, Ben Gamari wrote: > > > On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove > wrote: > > Snip. > > > >My questions for you: > > > >- Is there a reason that there are no derived 'Show' instances for most > > types? > > As Richard mentioned,

Re: Why are there no Show instances for internal types

On 19-03-17 02:08:56, Rahul Muttineni wrote: > Syd, can you tell us what kind of things you were trying to print out? Maybe I wasn't very clear. I'm trying to visualise the internal structure of some of the typechecker's output. I specifically do NOT need to see the output of Outputable's

Re: Why are there no Show instances for internal types

Rahul Muttineni writes: > 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. >

Re: Why are there no Show instances for internal types

Am Samstag, den 18.03.2017, 14:03 +0100 schrieb Tom Sydney Kerckhove: > > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace) You can often get away with showSDocUnsafe . ppr :: Outputable a => a -> String Greetings, Joachim -- Joachim “nomeata” Breitner  

Re: Why are there no Show instances for internal types

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

Re: Why are there no Show instances for internal types

On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove wrote: Snip. > >My questions for you: > >- Is there a reason that there are no derived 'Show' instances for most > types? As Richard mentioned, we don't derive Show due to code size and compilation time

Re: Why are there no Show instances for internal types

And I guess it would be bad to use Show, but make custom instances for the problematic types that did not loop? Alan On 18 Mar 2017 9:44 pm, "Edward Z. Yang" wrote: > We can't add Show instances for these types because many types > below them, e.g., Type, are cyclic, and would

Re: Why are there no Show instances for internal types

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

Re: Why are there no Show instances for internal types

My take is that we don't have these because they would slow down compilation times and add bloat. But enough people have asked for them (and, I can think of a few times when I would use them myself) that I think they should be added. It is conceivable that we could make the instances only when

Why are there no Show instances for internal types

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