[More checkpointing of c07 comment processing John Goerzen **20080311063645] { hunk ./en/ch07-typeclasses.xml 224 - this one color type. We could define equality tests for any anything + this one color type. We could define equality tests for anything hunk ./en/ch07-typeclasses.xml 227 - works the same as making Haskell's == operator + is exactly how you can make Haskell's == operator hunk ./en/ch07-typeclasses.xml 244 - Well-known typeclasses + Important Built-In Typeclasses hunk ./en/ch07-typeclasses.xml 255 - complete definition. + complete definition. FIXME: add link to lib ref hunk ./en/ch07-typeclasses.xml 271 - show. It takes one argument: the type to convert. - It returns a &String; representing that type. + show. It takes one argument: the data to convert. + It returns a &String; representing that data. hunk ./en/ch07-typeclasses.xml 288 - printStrLn: + putStrLn: hunk ./en/ch07-typeclasses.xml 321 + + &Show; is usually used to define a &String; + representation for data that is useful for a machine to parse + back with &Read;. Haskell programmers generally write custom + functions to format data in pretty ways for displaying to end + users, if this representation would be different than expected + via &Show;. + + hunk ./en/ch07-typeclasses.xml 367 + + In most cases, if the explicit &Double; type annotation + were omitted, the compiler would refuse to guess a + common type and simply give an error. The fact that it could + default to &Integer; here is a special case arising from the + fact that the literal 2 is treated as an + &Integer; unless a different type of expected for it. + + hunk ./en/ch07-typeclasses.xml 380 - as well. You'll need to explicitly cast your &read; results in + as well. You'll need to explicitly give types for + your &read; results in hunk ./en/ch07-typeclasses.xml 397 - when the return value was expected to be &Integer; then it did when a + when the return value was expected to be &Integer; than it did when a hunk ./en/ch07-typeclasses.xml 402 - The &Read; class provides for some fairly complicated parsers. Most - people, however, choose to use Parsec for complicated parsers these - days. FIXME: insert xref to parsec You can - define a simple parser by providing an implementation for the + The &Read; class provides for some fairly complicated parsers. + You can define a simple parser by providing an implementation for the hunk ./en/ch07-typeclasses.xml 422 - accept leading spaces, that attempt would work. + accept leading spaces, that attempt would work. You could + rectify this by modifying your &Read; instance to discard any + leading spaces, which is common practice in Haskell programs. hunk ./en/ch07-typeclasses.xml 426 + + + While it is possible to build sophisticated parsers using + the &Read; typeclass, many people find it easier to do so using + Parsec, and rely on &Read; only for simpler tasks. Parsec + is covered in detail in . + + hunk ./examples/ch07/eqclasses.hs 61 - show Red = "Red" + show Red = "Red" hunk ./examples/ch07/eqclasses.hs 63 - show Blue = "Blue" + show Blue = "Blue" hunk ./examples/ch07/read.hs 5 - let inpInt = (read inpStr)::Double - putStrLn ("Twice " ++ show inpInt ++ " is " ++ show (inpInt * 2)) + let inpDouble = (read inpStr)::Double + putStrLn ("Twice " ++ show inpDouble ++ " is " ++ show (inpDouble * 2)) }