Как стать автором
Обновить

Комментарии 6

За комментарии на русском языке ещё не ругали? :)

Шутка! Статья отличная! Очень просто и понятно написано на не самом простом для изучения языке.

Могу два уточнения сделать:

  1. При выводе ошибки лучше добавлять позицию/строка где сломались. Это очень помогает тем, кто будет использовать библиотеку

  2. Конвертация в число не учитывает переполнение. Текущий код просто упадет если дать на вход число 12345, как пример. А нужно бы вернуть нормальную ошибку.

Так очень удобно просигнализировать клиенту, что вызывать tokenize по несколько раз не разрешается и принудительно обеспечить соблюдение этого условия во время компиляции.

Если вызывать метод несколько раз не разрешается - нужно делать его принимающим не ссылку &mut self, а значение mut self

Тю, я думал с нормальной теорией будет, про регулярные грамматики расскажут, конечные автоматы. А тут просто идут по строке и символы сравнивают. Есть же хорошо развитая теория, и довольно простая. И поняв ее принцип - написать нужный токенизатор на любом языке - простая задача.

Так всё-таки, статья о "Увлекательный лексический анализ языка Rust" или о "Увлекательный лексический анализ с помощью языка Rust"?

Я ожидал разбор самого Rust, но с первых абзацев закрались смутные сомнения :)

С моей точки зрения, в контексте решаемой задачи только первая (в итоге и выбранная) версия перечисления Token корректна. Токен - это неделимая смысловая единица входного языка; из таких единиц строятся высказывания на этом языке. Поэтому вторая предлагаемая версия - своего рода доведение до абсурда, просто сопоставление каждого символа алфавита некоторому идентификатору; расширив этот вариант до всех 256 символов ASCII, можно гордо заявить, что мы реализовали универсальный токенизатор для любого языка (пусть и без поддержки юникода), только вот толку от него?

Третья же версия - это уже не про лексемы, а про синтаксис. Определять, чему синтаксически соответствует токен, задача не лексера, а парсера. Да, для очень простых языков можно вообще не делать это разделение, но лучше всё-таки делать, это позволит более гибко модифицировать отдельные механизмы в дальнейшем.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий