removing ad hoc Show instances?

Mark Tullsen tullsen at galois.com
Tue Oct 2 00:45:54 BST 2012


Sorry for the delayed response ...

On Sep 26, 2012, at 1:31 AM, Alexander Bernauer wrote:

> Hi Mark,
> 
> On Tue, Sep 25, 2012 at 05:02:08PM -0700, Mark Tullsen wrote:
>>    (I'll forgo an excursus on the significant advantages of this and
>>    my diatribe against ad hoc Show instances.)
> 
> Sorry if this is obvious, but I am really interested in learning about
> these advantages. Also, I have heard different opinions on for which
> purposes Show should be used.

From my point of view, a good design approach is to separate these two concerns:

  - serialization/deserialization between values and String representations of Haskell values.
    - Show & Read are used for this.

  - "user friendly" input and output functions for types
     - other mechanisms (such as two more classes Input and 'MyShow') should be used for this.

By separating these two concerns:
  - We have have a separation of the serialization & debugging concern from the user-interface concern.

  - Debugging becomes much easier in ghci
    - the output of show is something we can cut/edit/paste from and into ghci

  - For first order types, t, we have this property:
      id == read . show

  - We can now use Haskell packages such as

      hstidy, groom, and pretty-show

    to do a better show, all which rely on the output of show being parseable as Haskel code.
    (Sure, these tools are a little ad hoc, but clearly very useful.)

- Mark

> 
> We once had a discussion on this list, that the Show instances of all
> AST nodes should be canonical, such that they can be parsed by the
> Haskell parser (see discussion starting from [1]). Unfortunatelly,
> nobody took the time to acutally do this. But I am still
> convinced that this is a good idea.
> 
> And AFAICS this goes hand in hand with what you are suggesting.
> However, the Haskell report does not enforce that automatically derived
> Show instances produce parsable strings: "Strings produced by showsPrec
> are usually readable by readsPrec [2]". Any wisdom or experience here? I
> would just give it a try.
> 
> If we agree on what we want I would volunteer to finally provide the
> proper patch.
> 
> We have ad-hoc Show instances in the following modules:
> - Data.Ident
> - Data.Error
> - Data.Position
> - Data.Node
> - Syntax.Constants (<- concerns [1])
> - Analysis.DefTable
> - Analysis.SemRep
> - Analysis.SemError
> - Parser.Tokens
> - Parser.ParserMonad
> 
> To which instances are you referring to?
> 
> Greetings
> 
> Alex
> 
> [1]
> http://projects.haskell.org/pipermail/language-c/2011-May/000065.html
> 
> [2] http://www.haskell.org/onlinereport/basic.html (6.3.3)
> _______________________________________________
> Language-c mailing list
> Language-c at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/language-c




More information about the Language-c mailing list