Лекции по построению компилятора на Pascal
РАСПРЕДЕЛЕННЫЕ СКАНЕРЫ ПРОТИВ ЦЕНТРАЛИЗОВАННЫХ
Структура лексического анализатора, которую я только что вам показал, весьма стандартна и
примерно 99% всех компиляторов используют что-то очень близкое к ней. Это, однако, не
единственно возможная структура, или даже не всегда самая лучшая.
Проблема со стандартным подходом состоит в том, что сканер не имеет никаких сведений о
контексте. Например, он не может различить оператор присваивания "=" и оператор
отношения "=" (возможно именно поэтому и C и Паскаль используют для них различные
строки). Все, что сканер может сделать, это передать оператор синтаксическому анализатору,
который может точно сказать исходя из контекста, какой это оператор. Точно так же,
ключевое слово "IF" не может быть посредине арифметического выражения, но если ему
случится оказаться там, сканер не увидит в этом никакой проблемы и возвратит его
синтаксическому анализатору, правильно закодировав как "IF".
С таким подходом, мы в действительности не используем всю информацию, имеющуюся в
нашем распоряжении. В середине выражения, например синтаксический анализатор "знает",
что нет нужды искать ключевое слово, но он не имеет никакой возможности сказать это
сканеру. Так что сканер продолжает делать это. Это, конечно, замедляет компиляцию.
В настоящих компиляторах проектировщики часто принимают меры для передачи
подробной информации между сканером и парсером, только чтобы избежать такого рода]
проблем. Но это может быть неуклюже и, конечно, уничтожит часть модульности в
структуре компилятора.
Альтернативой является поиск какого-то способа для использования контекстной
информации, которая исходит из знания того, где мы находимся в синтаксическом
анализаторе. Это возвращает нас обратно к понятию распределенного сканера, в котором
различные части сканера вызываются в зависимости от контекста.
В языке KISS, как и большинстве языков, ключевые слова появляются только в начале
утверждения. В таких местах, как выражения они запрещены. Также, с одним небольшим
исключением (много символьные операторы отношений), которое легко обрабатывается, все
операторы одно-символьны, что означает, что нам совсем не нужен GetOp.
Так что, оказывается, даже с много символьными токенами мы все еще можем всегда точно
определить вид лексемы исходя из текущего предсказывающего символа, исключая самое
начало утверждения.
Даже в этой точке, единственным видом лексемы, который мы можем принять, является
идентификатор. Нам необходимо только определить, является ли этот идентификатор
ключевым словом или левой частью оператора присваивания.
Тогда мы заканчиваем все еще нуждаясь только в GetName и GetNum, которые используются
так же, как мы использовали их в ранних главах.
Сначала вам может показаться, что это шаг назад и довольно примитивный способ.
Фактически же, это усовершенствование классического сканера, так как мы используем
подпрограммы сканирования только там, где они действительно нужны. В тех местах, где
ключевые слова не разрешены, мы не замедляем компиляцию, ища их.
ОБЪЕДИНЕНИЕ СКАНЕРА И ПАРСЕРА
Теперь, когда мы охватили всю теорию и общие аспекты лексического анализа, я наконец
готов подкрепит свое заявление о том, что мы можем приспособить много символьные
токены с минимальными изменениями в нашей предыдущей работе. Для краткости и
простоты я ограничу сам себя подмножеством того, что мы сделали ранее: я разрешу только
одну управляющую конструкцию (IF) и никаких булевых выражений. Этого достаточно для
демонстрации синтаксического анализа и ключевых слов и выражений. Расширение до
полного набора конструкций должно быть довольно очевидно из того, что мы уже сделали.