Laws for Show and Read?

Dannyu NDos

5 Jun 2019 5 Jun '19

3:45 a.m.

Shouldn't it be laws that "show" must be injective and "read" must be surjective? Without such laws, one could define: data Foo = Foo instance Show Foo where show _ _ = id instance Read Foo where readPrec = pfail which should be prevented.

Attachments:

attachment.html (text/html — 480 bytes)

Show replies by date

Dannyu NDos

5 Jun 5 Jun

3:47 a.m.

In the instance Show Foo, I mean "showsPrec" rather than "show". 2019년 6월 5일 (수) 16:45, Dannyu NDos 님이 작성:

...

Shouldn't it be laws that "show" must be injective and "read" must be surjective? Without such laws, one could define:

data Foo = Foo instance Show Foo where show _ _ = id instance Read Foo where readPrec = pfail

which should be prevented.

Niklas Hambüchen

10:18 a.m.

...

Shouldn't it be laws that "show" must be injective and "read" must be surjective? My opinion (and that of many others) is that

* Show and Read should be used only for debugging purposes or things that directly relate to Haskell data types when written as literals * whenever possible, use only the GHC-derived instances for those * for all other use cases, different explicit parsers or pretty-printers should be used. The GHC-derived instances also automatically make your desired laws mostly hold. Injectivity seems a bit off, given that e.g. (read "3" :: Int) == (read " 3 " :: Int) so whitespace stripping, parentheses etc. allow different inputs to map to same outputs. Niklas

Li-yao Xia

10:32 a.m.

Hi Dannyu, On 6/5/19 3:45 AM, Dannyu NDos wrote:

...

Shouldn't it be laws that "show" must be injective and "read" must be surjective? Without such laws, one could define:

data Foo = Foo instance Show Foo where show _ _ = id instance Read Foo where readPrec = pfail

which should be prevented.

This doesn't look like something anyone would ever want to do, even out of ignorance. So that example is not really compelling. What is your general motivation to add "laws" to Show and Read? Li-yao

David Feuer

11:02 a.m.

We already have the law read . show = id which implies the injectivity and surjectivity conditions you specify. On Wed, Jun 5, 2019, 3:45 AM Dannyu NDos wrote:

...

Shouldn't it be laws that "show" must be injective and "read" must be surjective? Without such laws, one could define:

data Foo = Foo instance Show Foo where show _ _ = id instance Read Foo where readPrec = pfail

which should be prevented. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Sven Panne

2:55 p.m.

Am Mi., 5. Juni 2019 um 17:02 Uhr schrieb David Feuer

...

:

...

We already have the law

read . show = id

which implies the injectivity and surjectivity conditions you specify.

I think this doesn't hold for the standard Read/Show instances for Double/Float: IEEE-754 NaNs have a sign bit and a payload, and both parts are probably lost by the "read . show"-combination. The 2 infinities are probably OK, but what about -0 vs. +0?

David Feuer

3:15 p.m.

Double and Float instances are terminally broken in general. What's new? On Wed, Jun 5, 2019, 2:56 PM Sven Panne wrote:

...

Am Mi., 5. Juni 2019 um 17:02 Uhr schrieb David Feuer < david.feuer@gmail.com>:

...
We already have the law

read . show = id

which implies the injectivity and surjectivity conditions you specify.

I think this doesn't hold for the standard Read/Show instances for Double/Float: IEEE-754 NaNs have a sign bit and a payload, and both parts are probably lost by the "read . show"-combination. The 2 infinities are probably OK, but what about -0 vs. +0?

Bertram Felgenhauer

4:37 p.m.

Sven Panne wrote:

...

We already have the law read . show = id which implies the injectivity and surjectivity conditions you specify.

I think this doesn't hold for the standard Read/Show instances for Double/Float: IEEE-754 NaNs have a sign bit and a payload, and both parts are probably lost by the "read . show"-combination. The 2 infinities are probably OK, but what about -0 vs. +0?

ghci> show (-0 :: Double) "-0.0" ghci> read (show (-0 :: Double)) :: Double -0.0 It's true that extra information in NaNs is lost, but they all behave the same anyway... Cheers, Bertram

Sven Panne

5:14 p.m.

Am Mi., 5. Juni 2019 um 22:57 Uhr schrieb Bertram Felgenhauer via Libraries :

...

[...] It's true that extra information in NaNs is lost, but they all behave the same anyway...

That's true for normal arithmetic with them, but wrong if you use e.g. an external library which encodes things into the sign bit/paylod of NaNs (see e.g. NaN tagging). In the latter case, "read . show" actively destroys necessary information.

Carter Schonwald

6 Jun 6 Jun

11:51 p.m.

@Sven Panne you are correct, and its definitely true that 1) we dont have informative literals for +/- infity OR the bits in the nan. and those are truely informative in debugging, as IEEE float and show/read intend! so i support and would like to improve that state of affairs myself! (eg my slow motion ghc float ieee improvement stuff, most recently removing x87 support to make rounding deterministic for a change on x86 32 platform!) On Wed, Jun 5, 2019 at 5:15 PM Sven Panne wrote:

...

Am Mi., 5. Juni 2019 um 22:57 Uhr schrieb Bertram Felgenhauer via Libraries :

...
[...] It's true that extra information in NaNs is lost, but they all behave the same anyway...

That's true for normal arithmetic with them, but wrong if you use e.g. an external library which encodes things into the sign bit/paylod of NaNs (see e.g. NaN tagging). In the latter case, "read . show" actively destroys necessary information. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Ben Franksen

16 Jun 16 Jun

11:32 a.m.

Am 07.06.19 um 05:51 schrieb Carter Schonwald:

...

@Sven Panne you are correct, and its definitely true that 1) we dont have informative literals for +/- infity OR the bits in the nan. and those are truely informative in debugging, as IEEE float and show/read intend!

FWIW, my take is that the prefix (-) should be eliminated from Haskell as an operator (we have negate method for that). Instead, prefix + and - (no space allow in between) should be part of the syntax of numeric literals. This would solve a lot of problems, including the one mentioned.

2165

Age (days ago)

2176

Last active (days ago)

List overview

Download

10 comments

8 participants

participants (8)

Ben Franksen
Bertram Felgenhauer
Carter Schonwald
Dannyu NDos
David Feuer
Li-yao Xia
Niklas Hambüchen
Sven Panne

Laws for Show and Read?

tags

participants (8)