Hi Thomas, So "show . read" and "\x -> show (read x)" are actually mean different things? Also, I never suspected that something like this should succeed: putStrLn $ (read . show) $ "!@#%$^DFD" Thanks, -John On Mon, Dec 8, 2008 at 12:38 AM, Thomas Hartman wrote:

John,

By convention, read . show is supposed to be id.

However, in real life, this is often not the case. It all depends on the implementor, and this is a convention that seems to be broken pretty frequently.

Often there is a show instance with no read or vice versa, and sometimes even when there is both read and show they are not inverses.

Thomas.

main = show . read

Am 7. Dezember 2008 14:11 schrieb John Ky :

...

Hi,

Is there a way to read Showables?

main = do putStrLn $ show $ read

Thanks

-John

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Thanks for the clarification. They're all the same, as you've explained: Prelude> putStrLn $ (show . read) "123" *** Exception: Prelude.read: no parse Prelude> putStrLn $ show $ read "123" *** Exception: Prelude.read: no parse Prelude> putStrLn $ (\x -> show (read x)) "123" *** Exception: Prelude.read: no parse -John On Mon, Dec 8, 2008 at 12:08 PM, Jonathan Cast wrote:

On Mon, 2008-12-08 at 11:16 +1100, John Ky wrote:

...

Hi Thomas,

So "show . read" and "\x -> show (read x)" are actually mean different things?

No. Of course not. But there's no guarantee that

show (read x) = x

either.

...

Also, I never suspected that something like this should succeed:

putStrLn $ (read . show) $ "!@#%$^DFD"

Of course it succeeds. You put the `show' first; show always succeeds and --- for the Show instances in the Prelude, plus some ---

read (show x) = x

for finite, total x.

(Note that read . show /= show . read; they don't even have the same type!

show . read :: forall alpha. Show alpha => String -> String read . show :: forall alpha beta. (Read alpha, Show beta) => alpha -> beta

NB: The reason why show . read is illegal should be screaming out at you about now. The caveat --- other than the one I mentioned above --- to claims that read . show = id should also be screaming out.)

jcc

2008/12/7 John Ky :

Thanks for the clarification.

They're all the same, as you've explained:

Prelude> putStrLn $ (show . read) "123" *** Exception: Prelude.read: no parse

Prelude> putStrLn $ show $ read "123" *** Exception: Prelude.read: no parse

Prelude> putStrLn $ (\x -> show (read x)) "123" *** Exception: Prelude.read: no parse

Luke explained why the Exception is raised, I'll try to explain why this kind of problem happens in general: First two ways that work: Prelude> putStrLn $ (show :: Int -> String) . read $ "123" 123 Prelude> putStrLn $ show . (read :: String -> Int) $ "123" 123 In these examples we explicitly typed either the polymorphic producer (i.e. read) or the producer (i.e. show) so ghci can unify the type variables and figure out what is the right instance of the type class. Generally this happen wherever the type class member has a type variable only to the right of the type (either foo :: a or foo :: Something ->a). This kind of member is polymorphic on the result so the caller must define what it's expecting. "show . read" is saying to ghc both the result of read will define the type and the argument of show will define the type, which is a (kind of) mutually recursive typing issue.

-John

Best regards, Daniel Yokomizo