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