removing ad hoc Show instances?

[Benedikt Huber]

On 10/14/2012 05:54 AM, Mark Tullsen wrote:
> On Oct 10, 2012, at 7:59 AM, Benedikt Huber wrote:
>
>> Hello!
>>
>> First, I do agree it is desirable that show produces strings which can be both read (via readsPrec) and parsed by the haskell compiler.
>>> Could you maybe motivate, why all these user-defined Show instances are
>>> such an annoyance to you that you even consider forking Language.C to
>>> get rid of them?
> See below: I wanted to use one of the packages groom or pretty-show to get indented, human-readable output from show.
> Neither of these works if the output of Show isn't parseable Haskell.
Interesting, groom looks very useful. Also, I like the possibility to 
show an example and copy the output into ghci or a haskell source.

>>>> (But maybe we need another class 'ConciseShow'---or the like---so as
>>>> not to throw away the code that previously showed these values.)
>>>
>>> I am pretty sure that one or the other implementation of show is
>>> actually needed, so ConciseShow or MyShow etc. will in fact be required.
>> Are there cases where Pretty won't do the job?
This question is still open - if we would replace all Show instances, do 
we need another class, or is it ok to go with Pretty?

>> Concluding, I'm not opposed to this change, although it has the potential to silently break clients; maybe it would be a good idea to check if there are packages without < 0.5 upper bounds and if c2hs still works after this change.
>> Mark, do you have a patch ready?
>
> Actually, I've found a couple workarounds:
So I guess you did not actually implement the changes (i.e., replacing 
Show instances by haskell-parseable ones) in language-c?

>     groomString . gshow   -- #1 using the groom package with gshow
>     pprint                -- #2 a hacked version of pprint from the data-pprint package; a little ugly.
>
> The goal is to have indented shows of the C AST (really nice when one is getting up to speed on language-c!).
I briefly tested (groomString . gshow), and it did not work too well. 
First, ghow's output is really ugly, especially when it comes to lists. 
Second, groomString causes a stack overflow for moderately large (5000 
LoC) C files. I did not look into pprint.

> So, in principle, I think removing "ad hoc" show instances is a good thing; in practice I've got a workaround.
> So, if the change doesn't seem highly desired, I'm fine with just dropping this request.
Well, I'm fine with the change (with the caveats I mentioned before), 
and I think Aaron is in favor of it. If you'd rather stick with the 
workaround, maybe there is a way to integrate the pprint stuff?

cheers, benedikt