Quantcast

Why are there no Show instances for internal types

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Why are there no Show instances for internal types

Tom Sydney Kerckhove
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.

--
Tom Sydney Kerckhove

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Richard Eisenberg-4
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 DEBUG is on. That would, I believe, involve some unsavory CPP, and may not be worth it. What do others think?

Richard

> On Mar 18, 2017, at 9:03 AM, Tom Sydney Kerckhove <[hidden email]> wrote:
>
> 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.
>
> --
> Tom Sydney Kerckhove
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Edward Z. Yang
In reply to this post by Tom Sydney Kerckhove
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Alan & Kim Zimmerman
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" <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Ben Gamari-2
In reply to this post by Tom Sydney Kerckhove


On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove <[hidden email]> 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 concerns. Show in particular is rather expensive to derive and seeing as we already have Outputable I don't it would make sense to derive it by default. I would really like to avoid introducing more CPP into the code base for this particular problem.

One alternative which will work in many cases is to simply derive Show yourself using StandaloneDeriving. Does this help?

Cheers,

- Ben

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Rahul Muttineni
In reply to this post by Edward Z. Yang
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



-- 
Rahul Muttineni

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Joachim Breitner-2
In reply to this post by Tom Sydney Kerckhove
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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Ben Gamari-2
In reply to this post by Rahul Muttineni
Rahul Muttineni <[hidden email]> 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.
>
Indeed, I would love to see this happen. This exact request is being
tracked as #10143.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Edward Z. Yang
In reply to this post by Rahul Muttineni
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 <[hidden email]> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Tom Sydney Kerckhove
In reply to this post by Rahul Muttineni
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 functions.
They show the human-readibly version and not the internal structure.

Does that answer your question?

> Hope that helps,
> Rahul
>
> On Sun, Mar 19, 2017 at 1:14 AM, Edward Z. Yang <[hidden email]> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Rahul Muttineni
--
Tom Sydney Kerckhove

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Tom Sydney Kerckhove
In reply to this post by Ben Gamari-2
On 18-03-17 16:13:52, Ben Gamari wrote:

>
>
> On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove <[hidden email]> 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 concerns.
Okay.

> Show in particular is rather expensive to derive and seeing as we already have Outputable I don't it would make sense to derive it by default.

Show and Outputable have very different goals though.

> I would really like to avoid introducing more CPP into the code base for this particular problem.

Fair enough.

> One alternative which will work in many cases is to simply derive Show yourself using StandaloneDeriving. Does this help?

That doesn't work if some type doesn't have the constructors exposed.
I tried this already, and it would be a good solution if all
constructors were exposed, ...

> Cheers,
>
> - Ben
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
Tom Sydney Kerckhove

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Ben Gamari-2
In reply to this post by Tom Sydney Kerckhove
Tom Sydney Kerckhove <[hidden email]> 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.
> I specifically do NOT need to see the output of Outputable's functions.
> They show the human-readibly version and not the internal structure.
>
Indeed I am sympathetic to this request. In my time working on GHC I
have written raw several variants of `Type -> SDoc`, each exposing
various levels of detail. These are handy and can be a good way to gain
insight into the AST, but I feel like it is hard to come up with
something that is generally applicable; I find each time I need to
expose slightly different details about the internal structure of the
representation.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Why are there no Show instances for internal types

GHC - devs mailing list
In reply to this post by Tom Sydney Kerckhove

| > >- 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 would make sense to derive it by
| default.
|
| 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 to really really see the precise data constructors used.  But for the most part the Outputable instance tells you that, but much more legibly.

Simon
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why are there no Show instances for internal types

Joachim Breitner-2
Hi,

Am Montag, den 20.03.2017, 12:51 +0000 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 to really really see the precise data constructors
> used.  But for the most part the Outputable instance tells you that,
> but much more legibly.

and if using Outputable is a bit annoying sometimes (e.g. I found it
hard to get the IdInfo of an Id that is not part of a binder, if I
recall correctly, because the default instance does not include that
info, and the pretty printer for “id with idinfo” is not exported),
well, we can always improve that by adding a few more helpful functions
to Outputable.

Greetings,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Loading...