Это работа Лексера для разбора чисел и строк?

Является ли это задачей lexer для разбора чисел и строк?

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

Действительно ли это лексерская работа? Или лексер просто разбивает строку типа 123.456 на строки 123, ., 456 и позволяет анализатору выяснить остальное? Выполнение этого не было бы так просто с помощью строк...

Ответ 1

Простым ответом является "Да".

В реферате вам вообще не нужны лексеры. Вы могли бы просто написать грамматик, который использовал отдельные символы в качестве токенов (и на самом деле именно то, что делают синтаксические анализаторы SGLR, но это история за другой день).

Вам нужны лексеры, потому что парсеры, созданные с использованием символов в качестве примитивных элементов, не так эффективны, как парсеры, которые разбивают входной поток на "токены", где токены - это примитивные элементы языка, который вы разыгрываете (пробелы, ключевые слова, идентификаторы, числа, операторы, строки, комментарии,...). [Если вы не заботитесь об эффективности, вы можете пропустить оставшуюся часть этого ответа и почитать о синтаксисе SGLR].

Хорошие лексеры обычно принимают наборы регулярных выражений, представляющих языковые элементы, и компилируют их в эффективный конечный конечный автомат, который может быстро сегментировать входной поток на такие языковые элементы. (Если вы не хотите, чтобы пользователь использовал генератор лексеров, для простых языков вы можете самостоятельно закодировать FSA). Такие скомпилированные FSA выполняют только несколько десятков машинных инструкций для каждого входного символа (получить символ из входного буфера, переключить символ в новое состояние, решить, завершен ли токен, если он не повторится), и поэтому может быть чрезвычайно быстрым.

Вывод таких лексеров обычно представляет собой код, представляющий элемент langauge (или ничего для пробелов, если парсер в любом случае игнорирует его) и некоторую информацию о местоположении (начинается в файле foo, строка 17, столбец 3), чтобы включить отчет об ошибках.

Можно остановиться там и иметь полезные лексеры. Часто бывает полезно сделать шаг преобразования, который преобразует строку символов в эквивалентное значение собственного компьютера для этого токена, либо по мере того, как символы собираются, либо когда токен завершен, потому что у него все еще есть знания о конкретных символах, участвующих в токен. Это используется для преобразования чисел (различных радиксов) на целевом языке в их родной двоичный эквивалент, для преобразования литеральных строк, содержащих escape-последовательности, в фактические символы, составляющие строку, и даже с именами идентификаторов и поиска их в хеш-таблице так что идентичные идентификаторы легко определяются. Парсер обычно не интересуется этими преобразованными значениями, но шаги, выходящие за рамки синтаксического анализа (семантический анализ, проверка для оптимизации, генерация кода), все равно нуждаются в преобразованных значениях, поэтому вы можете также преобразовать их, когда вы их обнаружите. (Вы можете отложить это преобразование до тех пор, пока не потребуется их двоичное значение, но на практике вам почти всегда нужно значение, поэтому отсрочка конвертации не очень сильно покупается).

Ответ 2

Я предполагаю, что вы хотите рассматривать "123.456" как целое значение, и в этом случае вы передадите его оптовой парсером, если вам не нужно каким-либо образом его кодировать, например

struct DecimalRep{
    double mantissa,
    double exponent 

}

но я думаю, что все зависит от того, что ожидает парсер.

Ответ 3

Лексер по существу идентифицирует TOKENs от ввода. В этом случае лексер, возможно, "сопоставит" число как число с плавающей точкой TOKEN. Парсер по существу обрабатывает токены и делает синтаксический анализ.