RE: [Haskell] Read Instances for Data.Map and Data.Set
On 21 October 2005 08:43, Johannes Waldmann wrote:
Georg made the point that if a type is an instance of Show, then it should also be an instance of Read, and read . show == id
I rather think that this should be an explicit design requirement for Read/Show instances in the libraries, along with the requirement that the Show instance outputs valid Haskell syntax that can be included in a program (assuming appropriate imports, and possibly an appropriate type signature). Show is not for pretty-printing, it is for serialising. Are there any Show instances that violate these requirements in the base/haskell98 packages currently? Cheers, Simon
Simon Marlow wrote:
the Show instance outputs valid Haskell syntax that can be included in a program (assuming appropriate imports, and possibly an appropriate type signature).
The Data.Map Show instance is breaking exactly this requirement (by using braces), and that's why I want to avoid it. See my post cited earlier. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Am Freitag, 21. Oktober 2005 11:22 schrieb Simon Marlow:
On 21 October 2005 08:43, Johannes Waldmann wrote:
Georg made the point that if a type is an instance of Show, then it should also be an instance of Read, and read . show == id
I rather think that this should be an explicit design requirement for Read/Show instances in the libraries, along with the requirement that the Show instance outputs valid Haskell syntax that can be included in a program (assuming appropriate imports, and possibly an appropriate type signature). Show is not for pretty-printing, it is for serialising.
Are there any Show instances that violate these requirements in the base/haskell98 packages currently?
AFAIK not, but the "new" Show instances of Data.Map and such like do not follow this requirement, since they introduce new syntax like: { a := b,..} and < 1,2,3 > ... Therefore I would suggest to change these instances to something like: show $ Data.Map.fromList [(1,"Foo"),(2,"Bar")] = "Data.Map.fromList [(1,\"Foo\"),(2,\"Bar\")]" It uses the ordinary List syntax and the constructing function is given as well. Cheers, Georg
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Georg Martius Institut für Informatik Universität Leipzig Tel.: +49 341 9732284
Am Freitag, 21. Oktober 2005 11:22 schrieb Simon Marlow:
On 21 October 2005 08:43, Johannes Waldmann wrote:
Georg made the point that if a type is an instance of Show, then it should also be an instance of Read, and read . show == id
I rather think that this should be an explicit design requirement for Read/Show instances in the libraries, along with the requirement that the Show instance outputs valid Haskell syntax that can be included in a program (assuming appropriate imports, and possibly an appropriate type signature). Show is not for pretty-printing, it is for serialising.
Are there any Show instances that violate these requirements in the base/haskell98 packages currently?
AFAIK not, but the "new" Show instances of Data.Map and such like do not follow this requirement, since they introduce new syntax like: { a := b,..} and < 1,2,3 > ... Therefore I would suggest to change these instances to something like: show $ Data.Map.fromList [(1,"Foo"),(2,"Bar")] = "Data.Map.fromList [(1,\"Foo\"),(2,\"Bar\")]" It uses the ordinary List syntax and the constructing function is given as well. Cheers, Georg
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
simonmar:
On 21 October 2005 08:43, Johannes Waldmann wrote:
Georg made the point that if a type is an instance of Show, then it should also be an instance of Read, and read . show == id
I rather think that this should be an explicit design requirement for Read/Show instances in the libraries, along with the requirement that the Show instance outputs valid Haskell syntax that can be included in a program (assuming appropriate imports, and possibly an appropriate type signature). Show is not for pretty-printing, it is for serialising.
Are there any Show instances that violate these requirements in the base/haskell98 packages currently?
The ones I can think of off the top of my head. Of course, these are weird for various reasons though: > show $ toDyn (1::Int) -- Dynamic has no Read "<<Int>>" > show $ typeOf (1::Int) -- TypeRep as no Read "Int" PackedString has no Read, but could have one. Due to Autrijus: instance Read FastString where readsPrec p str = [ (pack x, y) | (x, y) <- readsPrec p str ] or some tricky packed version a la Binary and .hi files. None of these is terribly troubling though, I think. -- Don
On 10/21/05, Simon Marlow
I rather think that this should be an explicit design requirement for Read/Show instances in the libraries, along with the requirement that the Show instance outputs valid Haskell syntax that can be included in a program (assuming appropriate imports, and possibly an appropriate type signature). Show is not for pretty-printing, it is for serialising.
BTW, I noticed with slight horror that Data.Tree.Tree gained labeled fields in GHC 6.4, and of course they are included in the output of derived Show. This makes Tree's show'ed in 6.4 unreadable in earlier versions of GHC (like 6.2.2). Also, such represenation is too lenghty IMO. Perhaps rootLabel and subForest could be ordinary functions (but this could break someones code), or we could use a hand-written Show instance, showing without labels and reading both versions? Best regards Tomasz
On 10/24/05, Tomasz Zielonka
Perhaps rootLabel and subForest could be ordinary functions (but this could break someones code), or we could use a hand-written Show instance, showing without labels and reading both versions?
Wouldn't it be nice if derived Show for data-types with labeled fields accepted both labeled and un-labeled representations? Would this break standard conformance? Best regards Tomasz
On Mon, Oct 24, 2005 at 02:58:03PM +0200, Tomasz Zielonka wrote:
BTW, I noticed with slight horror that Data.Tree.Tree gained labeled fields in GHC 6.4, and of course they are included in the output of derived Show. This makes Tree's show'ed in 6.4 unreadable in earlier versions of GHC (like 6.2.2). Also, such represenation is too lenghty IMO.
Perhaps rootLabel and subForest could be ordinary functions (but this could break someones code), or we could use a hand-written Show instance, showing without labels and reading both versions?
Sorry, I didn't think about Read. Maybe I should make them functions. However it's quite common to define fields even when you only want the extractor, especially with newtypes.
participants (7)
-
dons＠cse.unsw.edu.au -
Georg Martius -
Georg Martius -
Johannes Waldmann -
Ross Paterson -
Simon Marlow -
Tomasz Zielonka