removing ad hoc Show instances?

[Mark Tullsen]

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.
> However, while it is certainly convenient to use "deriving (Show,Read)", doing so might expose implementation details and is only possible if all data constructors are exported (consider e.g. Data.Map).
> 
> On 10/08/2012 10:25 PM, Alexander Bernauer wrote:
>> On Mon, Oct 08, 2012 at 12:23:41PM -0700, Mark Tullsen wrote:
>>> - That is, readsPrec should be able to parse the string produced by
>>> showsPrec, and should deliver the value that showsPrec started with.
>>> 
>>>  - The result of show is a syntactically correct Haskell expression
>>>  containing only constants, given the fixity declarations in force at
>>>  the point where the type is declared.
>> 
>> Just to complete the picture: if user defined Show instances would
>> produce syntactically correct Haskell expressions and there would also
>> be corresponding Read instances, would that be also okay?
>> 
>> For example, Data.Ident contains an "hash to speed up equality check" of
>> type Int. The value can be calculated from the identifier itself. So one
>> could have a Show instance omitting the hash and a Read instance
>> re-calculating it.
> It would be reasonable (but not absolutely necessary) to have a custom Show instance in this case, to avoid the unneccessary exposal of the implementation detail "hash to speed up equality check". I guess the CNode information needs to be included to ensure (read.show ~ id).
> 
>>> That's exactly right, I'd like to see all of them removed.
>> Hmm, that's quite a change.
>> 
>> We will have to carefully check for which purpuses those instances are
>> used currently. Some instances such as those in Data.Error and
>> Parser.Tokens seem to be specifically crafted.
>> 
>> I could find and adapt all points of usage in the library itself, but how
>> should we handle existing client code? Break it and release Language.C
>> 0.5?
> Yes, bump to 0.5, although this upgrade is not unlikely to introduce bugs in a silent way (consider e.g. show someIdent ++ " = 3.14;")
> 
>> 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?
> I understand the general idea, but would also love to hear an actual example where the current Show instances where troublesome.
> 

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.


>>> (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?
> 
> 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:
  
   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!).

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.

Thanks,

Mark

> 
> cheers, benedikt
> 
> 
> _______________________________________________
> Language-c mailing list
> Language-c at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/language-c