Собственный интерпретатор

На этом этапе вы добавите поддержку сообщений об ошибках при распознавании недопустимых токенов, таких как $, # и т. д.

Ссылка на книгу

Код для этого этапа реализован в разделе 4.5.1: Лексические ошибки.

Проверки

Тестирующая система выполнит серию проверок с файлами test.lox, содержащими неизвестные токены вместе с другими ранее введёнными типами токенов.

Например, если test.lox содержит следующее:

,.$(#

Тестирующая система запустит вашу программу следующим образом:

$ ./your_program.sh tokenize test.lox
[line 1] Error: Unexpected character: $
[line 1] Error: Unexpected character: #
COMMA , null
DOT . null
LEFT_PAREN ( null
EOF  null

Ошибки следует выводить в поток stderr с префиксом [line N]. Если обнаружены лексические ошибки, ваша программа должна завершиться с кодом 65.

Тестирующая система проверит, что:

• Поток stderr содержит по одной строке для каждой лексической ошибки (при их наличии).
  • Каждая строка должна соответствовать формату [line N] Error: Unexpected character: <character>.
• Поток stdout содержит по одной строке для каждого корректного токена (даже при наличии других лексических ошибок).
• Ваша программа завершается с кодом 65, если есть лексические ошибки, и с кодом 0 в противном случае.

Поскольку символ новой строки ещё не введён, все ошибки будут начинаться с [line 1]. К ошибкам на разных строках мы перейдём на следующих этапах.

Примечания

• Этот формат вывода соответствует спецификации в репозитории книги
• Поскольку stdout и stderr — отдельные потоки, взаимный порядок ошибок и корректных токенов не важен. Вы можете выводить ошибки сначала, в конце или вперемешку с корректными токенами.
• Ошибками считаются только строки, начинающиеся с [line N], поэтому остальные строки в stderr можно использовать для отладки.
• При выделении токенов допускаются непарные круглые или фигурные скобки. На следующих этапах, когда мы перейдём к синтаксическому анализу выражений, такие случаи будут отмечаться как ошибки.