--- documents. Unlike the \<schedule_id\> and \<XML_File_ID\>
--- elements, the \<game_id\> can be missing from GameInfo
--- documents. So even the 'Right' value of the 'Either' can be
--- \"missing\". There are two reasons that the parse might fail.
---
--- 1. No such elements were found. This is expected sometimes, and
--- should be returned as a 'Right' 'Nothing'.
---
--- 2. An element was found, but it could not be read into an
--- 'Int'. This is NOT expected, and will be returned as a
--- 'ParseError', wrapped in a 'Left'.
---
--- Most of implementation for this ('parse_message_int') is shared,
--- but to handle the fact that game_id is optional, we pattern match
--- on the 'ParseError' that comes back in case of failure. If we
--- didn't find any game_id elements, we turn that into a
--- \"successful nothing\". But if we find a game_id and it can't be
--- parsed, we let the error propagate, because that shouldn't
--- happen. Of course, if the parse worked, that's nice too: we wrap
--- the parsed value in a 'Just' and return that wrapped in a 'Right'
+-- documents. Unlike the \<XML_File_ID\> elements, the \<game_id\>
+-- can be missing from GameInfo documents, so for our implementation
+-- we use 'parse_message_int_optional' instead.