Show instances for GHC internals

[Ömer Sinan Ağacan]

> There are more interesting parts of your post, but I can respond to this: It
> shouldn't take that much time. Once you have ghc-stage2 built, you should be
> able to say `make 2` in the ./ghc subdirectory and get a new binary in a few
> seconds.
>
> Using `make 1` in the ./compiler subdirectory works similarly for the stage1
> compiler. But only once it's built the first time.

I replied this in other thread, I think it works but I'll make sure next time I
do a `make clean`. Thanks.



Another problem is this: Hiding fields of types is great for safety reasons,
but not so great for debugging.

In CoreDump I'm having this problems:

- Sometimes GHC can't derive Show instance because record fields are hidden.
  But every field is actually exposed in a read-only way with some manually
  defined functions. This is super annoying. It'd be really awesome if we could
  export record fields as "read-only". (very half-baked idea)

- Sometimes fields are hidden, and no accessors are provided. This is even
  worse because now there's really no way to derive Show, using `deriving` or
  manually.

> (2) have unsafeInterleaveIO thunks which would induce IO action

Edward, do you remember any examples of such code?

2015-10-20 9:22 GMT-04:00 Ömer Sinan Ağacan <omeragacan at gmail.com>:
>> One difficulty is that many of the core type data types, e.g. TyThing,
>> are (1) a large mutually recursive graph, and (2) have
>> unsafeInterleaveIO thunks which would induce IO action.  So a naive
>> Show instance would give infinite output and have lots of side effects.
>> There are many data types which could usefully have Show added but
>> also many which would be very difficult to.
>
> Ah, yes, this is a very annoying problem. I discovered that when I first wrote
> CoreDump: https://github.com/osa1/CoreDump/issues/2
>
> I don't have solution to this yet.
>
> 2015-10-19 21:59 GMT-04:00 Edward Z. Yang <ezyang at mit.edu>:
>> Excerpts from Ömer Sinan Ağacan's message of 2015-10-19 14:18:41 -0700:
>>> I was wondering what would be the cost of adding Show instances. Would that
>>> mean significantly increased compile times? Or significantly bigger GHC
>>> binaries? If that's the case, could we enable Show instances with some
>>> arguments so that we can enable/disable it by modifying mk/build.mk?
>>
>> One difficulty is that many of the core type data types, e.g. TyThing,
>> are (1) a large mutually recursive graph, and (2) have
>> unsafeInterleaveIO thunks which would induce IO action.  So a naive
>> Show instance would give infinite output and have lots of side effects.
>> There are many data types which could usefully have Show added but
>> also many which would be very difficult to.
>>
>> Edward