removing ad hoc Show instances?

[Benedikt Huber]

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.

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

cheers, benedikt