Laws for Show and Read?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Laws for Show and Read?

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.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Laws for Show and Read?

Dannyu NDos
In the instance Show Foo, I mean "showsPrec" rather than "show".

2019년 6월 5일 (수) 16:45, Dannyu NDos <[hidden email]>님이 작성:
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Laws for Show and Read?

Niklas Hambüchen
In reply to this post by Dannyu NDos
> 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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Laws for Show and Read?

Li-yao Xia-2
In reply to this post by Dannyu NDos
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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Laws for Show and Read?

David Feuer
In reply to this post by Dannyu NDos
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Laws for Show and Read?

Sven Panne-2
Am Mi., 5. Juni 2019 um 17:02 Uhr schrieb David Feuer <[hidden email]>:
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?

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Laws for Show and Read?

David Feuer
Double and Float instances are terminally broken in general. What's new?

On Wed, Jun 5, 2019, 2:56 PM Sven Panne <[hidden email]> wrote:
Am Mi., 5. Juni 2019 um 17:02 Uhr schrieb David Feuer <[hidden email]>:
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?

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Laws for Show and Read?

Haskell - Libraries mailing list
In reply to this post by Sven Panne-2
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
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Laws for Show and Read?

Sven Panne-2
Am Mi., 5. Juni 2019 um 22:57 Uhr schrieb Bertram Felgenhauer via Libraries <[hidden email]>:
[...] 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Laws for Show and Read?

Carter Schonwald
[hidden email] 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 <[hidden email]> wrote:
Am Mi., 5. Juni 2019 um 22:57 Uhr schrieb Bertram Felgenhauer via Libraries <[hidden email]>:
[...] 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Laws for Show and Read?

Ben Franksen
Am 07.06.19 um 05:51 schrieb Carter Schonwald:
> @Sven Panne <[hidden email]> 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.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries