Hi! The Tree datatype in new Data.Tree module has a Show instance that works like shown below: Prelude Data.Tree> print (Node 'a' [Node 'b' [], Node 'c' []]) - 'a' -+- 'b' | `- 'c' I use a similar module for Trees in conjunction with WASH for generating web pages. WASH session management relies on the ability to read back previously showed values. Writing a Read instance for such Show would be a weird thing to do. I think it would be better to derive Show instance for Tree instead of providing a pretty printing one. Then it would be possible to have a complementing Read instance. The pretty printing function could be provided under a different name (eg. drawTree). The other tiny problem is that the current instance is not recursion-proof: Prelude Data.Tree> let f x = Node x [Node x [], Node x []] Prelude Data.Tree> print (f (f 1)) - - 1 -+- 1 | `- 1 -+- - 1 -+- 1 | `- 1 | `- - 1 -+- 1 | `- 1 Best regards, Tom -- .signature: Too many levels of symbolic links
On Mon, 11 Aug 2003, Tomasz Zielonka wrote:
The Tree datatype in new Data.Tree module has a Show instance ...
I agree that Read/Show should normally come as a pair. It is debatable whether a library should contain a Show instance that makes it rather impossible to write the corresponding Read instance. Even more so since no library user can later change this: by the Haskell definition, if you import a module that contains a data type definition, then you also inherit all its instances from that module. (Section 5.4 of the report, http://haskell.org/onlinereport/modules.html) the workaround would be to move the `instance Show Tree' into a separate library module. On the other hand, it is my opinion that for a clean program design, you should normally define your own `data' (or `newtype') types, rather than use exisiting ones by `type' synonyms. this may lead to somewhat larger program texts, but you'll find that they are more readable, and extendable. (Compare adding another component to a tuple, and to a record). this also gives you the opportunity to define class instances in any way you want. best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/209 --
On Tue, Aug 12, 2003 at 12:30:27PM +0200, Johannes Waldmann wrote:
On Mon, 11 Aug 2003, Tomasz Zielonka wrote:
The Tree datatype in new Data.Tree module has a Show instance ...
[...]
On the other hand, it is my opinion that for a clean program design, you should normally define your own `data' (or `newtype') types, rather than use exisiting ones by `type' synonyms.
this may lead to somewhat larger program texts, but you'll find that they are more readable, and extendable. (Compare adding another component to a tuple, and to a record).
this also gives you the opportunity to define class instances in any way you want.
I agree with you. I often define my own types using 'data' and 'newtype', even for things like IP adresses and numeric identifiers, because I don't need and don't want many operations that integral types provide but are meaningles in these applications. I also find datatypes with named fields convenient. And I rarely define type synonyms, probably only for some involved combinations of monad transformers. However, I think that there are some types so generic, that they deserve including in standard libraries. One example is a list - how often do you define your own list type? But lists form a subset of trees, and trees form a subset of graphs, so it would be nice to have them delivered with GHC even if they would only be used in toy applications. Best regards, Tom -- .signature: Too many levels of symbolic links
On Mon, Aug 11, 2003 at 07:16:08PM +0200, Tomasz Zielonka wrote:
I think it would be better to derive Show instance for Tree instead of providing a pretty printing one. Then it would be possible to have a complementing Read instance. The pretty printing function could be provided under a different name (eg. drawTree).
Thanks -- I've changed it as you suggest.
participants (3)
-
Johannes Waldmann -
Ross Paterson -
Tomasz Zielonka