Effective Haskell Chapter 11

@RebeccaSkinner
In Effective Haskell Chapter 11 (~ p 410 in ePub), when creating the Encode and Decode instances for String, pack and unpack are used, but given all the imports, ghci couldn’t resolve them so I needed to use the qualified names, BC.pack and BC.unpack.

Serializing FileMode (approx p. 413 in ePub) doesn’t work on Macs since CMode wraps a Word16, not Word32. I was baffled because the documentation on Hackage said CMode wraps a Word32, not realizing that the Hackage docs were probably generated on a Linux box. I ended up writing the encoding/decoding for Word16 so GHC could pick the right one.

When defining Encode to have encode and encodeWithSize (approx p 415 in ePub), the MINIMAL pragma is missing the # at the opening ( {- instead of {-# )

I assume there was some refactoring going on because the FileData type was defined with record fields: fileName, fileSize, filePermissions, and fileData, but the Encode instance uses packedFileName, packedFileSize, packedFilePermissions, and packedFileData.

The file pack example is a fun one for getting at these different data encodings.

@RebeccaSkinner

Serializing FileMode (approx p. 413 in ePub) doesn’t work on Macs since CMode wraps a Word16, not Word32.

Same here. I opened a PR mentioning that.

Some other small things:

When fileData :: a is introduced, it breaks packFiles and unpackFiles since a type enforcement is missing in the two functions—and it will only be solved again when existential types are introduced:

packFiles :: (Show a) => FilePack a -> ByteString
unpackFiles :: (Read a) => ByteString -> Either String (FilePack a)

On page 416, it says:

On the other hand, if we’re provided a valid implementation of encodeWithSize, we can come up with a valid implementation of decode by dropping off the leading size field.

However, it should say:

On the other hand, if we’re provided a valid implementation of encodeWithSize, we can come up with a valid implementation of encode by dropping off the leading size field.

On page 432:

After using existential types extension to build a Packable with a list of values that can be encoded makes “packFiles” and “unpackFiles” functions unusable since Packable erases type info and FilePack does not derive from Eq, Show, and Read type classes.

Thanks for the comment and the PR. As I mentioned on the PR, I want to make some space to show off reader solutions and call out people who have found bugs so that future readers can be warned, and so the folks who find the bugs are getting public credit.

2 Likes