removing ad hoc Show instances?

Mark Tullsen tullsen at galois.com
Tue Oct 16 23:39:19 BST 2012


On Oct 16, 2012, at 2:31 AM, Benedikt Huber wrote:

> 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.

Exactly.

> 
>>>>> (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?

Aren't you using Pretty to generate the C parseable output?

I was thinking of something comparable to Show such as this:

  class ConciseShow a where
    cShowsPrec        :: Int -> a -> ShowS
    cShow             :: a -> String

    cShowsPrec _ x s   = cShow x ++ s
    cShow x            = cShowsPrec 0 x ""


>>> 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?

That's right, I'm a pretty lazy guy :-).

> 
>>    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.

That's a bummer; good to know though.


> 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?

No, the 'pprint' stuff was a total hack: I was just trying to get a 'sane' indented printout.

- Mark





More information about the Language-c mailing list