cool! Thanks for sharing!
(i mean, who doesn't like to read a good book!)
Question: would it be worth considering internally having the digits be stored as half bytes for space usage? eg ISBN10 -> use ~ 5 bytes, and ISBN13 be ~ 7 bytes (this could be within a word64 as a tiny 8 slot array, OR or any sort of vector/array datatype)? (or instead of a decimal binary rep, pack it into a word64 as the number itself for either?) Granted this would complicate some of the internals engineering a teeny bit
it looks like, in the current code, if there's no hyphens, it'll keep the input text value as the internal rep, *which can cause space leaks* if it's a slice of a much larger text input you otherwise do not intend to retain. When it generates its own text string, well... the text package uses utf16 (aka 2 bytes per character for valid ascii) as the internal rep, so the buffer representation will occupy 10 * 2 bytes or 13* 2bytes, so 20-26 bytes within the buffer, ignoring the extra word or two of indexing/offsets!
point being ... it seems like could embed them (with a teeny bit of work) as follows
data ISBN =
IsIBSN10 ISBN10
| isISBN13 ISBN13
newtype ISBN10 = ISBN10 Word64
newtype ISBN13 = ISBN13 Word64
and then i'd probably be inclined to do use Data.Bits and do the "word 64 as a 16 slot array of word4's," which would also support the base 11 digit at the end encoding constraint, since word4 == base 16 :)
then a teeny bit of work to do the right "right" ords and shows etc on this rep etc
i hope the design i'm pointing out makes sense for you (and if i'm not being clear, please holler and i'll try to help)
and again, thanks for sharing this!
-Carter