Производственно-внедренческий кооператив
"И Н Т Е Р Ф Е Й С"
Диалоговая Единая Мобильная
Операционная Система
Демос/P 2.1
Генератор программ синтаксического анализа yacc
Москва
1988
Аннотация
Значительная часть создаваемых программ, рассчитанных
на определенную структуру входной информации, явно или
неявно включает в себя некоторую процедуру синтаксического
анализа. В задачах, где пользователю при задании входной
информации предоставляется относительная свобода (в отноше-
нии сочетания и последовательности структурных элементов),
синтаксический анализ достаточно сложен. При решении подоб-
ных задач существенную поддержку могут оказать сервисные
программы, осуществляющие построение синтаксических (грамма-
тических) анализаторов на основе заданных сведений о синтак-
сической структуре входной информации. yacc относится к
числу этих сервисных программ - генераторов синтаксических
анализаторов.
Поскольку обширной областью, где наиболее явно видна
необходимость (нетривиального) грамматического анализа, а
следовательно и его автоматизации, является область создания
трансляторов (в частности, компиляторов), программы, подоб-
ные yacc, получили еще название компиляторов (или генерато-
ров) компиляторов.
Заметим, что понятие транслятора может относиться не
только к языкам программирования, но и к командным языкам,
входным языкам любых диалоговых систем, языкам управления
технологическими процессами и т.п.
Пользователь yacc должен описать структуру своей вход-
ной информации (грамматику) как набор правил в виде, близком
к Бэкусово-Науровской форме (БНФ). Каждое правило описывает
грамматическую конструкцию, называемую нетерминальным симво-
лом, и сопоставляет ей имя. С точки зрения грамматического
разбора правила рассматриваются как правила вывода (подста-
новки). Грамматические правила описываются в терминах неко-
торых исходных конструкций, которые называются лексическими
единицами, или лексемами. Имеется возможность задавать лек-
семы непосредственно (литерально) или употреблять в грамма-
тических правилах имя лексемы. Как правило, имена сопостав-
ляются лексемам, соответствующим классам объектов, конкрет-
ное значение которых не существенно для целей грамматичес-
кого анализа. (Иногда в литературе с понятием лексемы совпа-
дает понятие терминального символа; однако, ряд авторов
называет терминальными символами отдельные символы стандарт-
ного набора). Примерами имен лексем могут служить идентифи-
катор и число, а введение таких лBексем позволяет обобщить
конкретные способы записи идентификаторов и чисел. В некото-
рых случаях имена лексем служат для придания правилам боль-
шей выразительности.
Лексемы должны распознаваться программой лексического
анализа, определяемой пользователем. Пользователь же предва-
рительно выбирает конструкции,которые более удобно и
эффективно распознавать непосредственно, и в соответствии с
этим объявляет имена лексем. Пользовательская программа лек-
сического анализа - лексический анализатор - осуществляет
чтение реальной входной информации и передает синтаксичес-
кому анализатору распознанные лексемы.
Как уже отмечалось, yacc обеспечивает автоматическое
построение лишь процедуры грамматического анализа. Однако,
действия по обработке входной информации обычно должны
выполняться по мере распознавания на входе тех или иных
допустимых грамматических конструкций. Поэтому наряду с
заданием грамматики входных текстов yacc предусматривает
воможность описания для отдельных конструкций семантических
процедур (действий) с тем, чтобы они были включены в прог-
рамму грамматического разбора. В зависимости от характера
пользовательских семантических процедур (интерпретация рас-
познанного фрагмента входного текста, генерация фрагмента
объектного кода, отметка в справочной таблице или форматиро-
вание вершины в дереве разбора) генерируемая с помощью yacc
программа будет обеспечивать кроме анализа тот или иной вид
обработки входного текста, в частности, его компиляцию или
интерпретацию.
Итак, пользователь yacc подготавливает общее описание
(спецификации) обработки входного потока, включающее пра-
вила, описывающие входные конструкции, кодовую часть, к
которой должно быть организовано обращение при обнаружении
этих конструкций, и программу ввода базовых элементов потока
(лексический анализатор). Kомпилятор компиляторов обеспечи-
вает создание подпрограммы (синтаксического анализатора),
реализующей процедуру обработки входного потока в соответст-
вии с заданными спецификациями.
yacc написан на языке Си и работает под управлением
системы ДЕМОС.
К компонентам компилятора компиляторов относятся выпол-
няемый файл yacc, библиотека стандартных программ
/lib/liby.a, Файл /usr/lib/yaccpar. Заключительная фаза
построения компилятора требует применения компилятора языка
Си.
1. Принципы работы yacc
Грамматические анализаторы, создаваемые с помощью yacc,
реализуют так называемый LALR(1)-разбор, являющийся модифи-
кацией одного из основных методов разбора "снизу вверх" -
LR(k)-разбора (буквы L(eft) и R(ight) в обоих сокращениях
означают соответственно чтение входных символов слева нап-
раво и использование правостороннего вывода. Индекс в скоб-
ках показывает число предварительно просматриваемых лекси-
ческих единиц).
- 3 -
Любой разбор по принципу "снизу вверх" (или восходящий
разбор) состоит в попытке приведения всей совокупности вход-
ных данных (входной цепочки) к так называемому "начальному
символу грамматики" (это понятие будет объяснено в разделе
4.1) путем последовательного применения правил вывода.
В каждый момент грамматического разбора анализатор
находится в некотором состоянии, определяемом предысторией
разбора, и в зависимости от очередной лексемы предпринимает
то или иное действие для перехода к новому состоянию. Разли-
чают два типа действий: сдвиг, т.е. чтение следующей входной
лексемы, и свертку, т.е. применение одного из правил подс-
тановки для замещения нетерминалом последовательности симво-
лов, соответствующей правой части правила. Работа yacc по
генерации процедуры грамматического анализа заключается в
построении таблиц, которые для каждого из состояний опреде-
ляют тип действий анализатора и номер следующего состояния в
соответствии с каждой из входных лексем.
Любой метод разбора требует грамматик с определенными
свойствами. В этом смысле yacc предполагает контекстно-
свободные грамматики со свойствами LALR(1). LALR(1)-
грамматики, являясь подмножеством LR(1)-грамматик, допускают
при построении таблиц разбора сокращение общего числа состо-
яний за счет объединения идентичных состояний, различающихся
только набором символов-следователей (символов, которые
могут следовать после применения одного из правил вывода,
если разбор по этому правилу проходил через данное состоя-
ние). Другие грамматики являются неоднозначными для приня-
того в yacc метода разбора и вызовут конфликты (раздел 5).
Однако, если язык, описываемый данной грамматикой, в прин-
ципе допускает задание грамматики, однозначной для данного
метода разбора, то yacc позволяет без перестройки грамматики
построить грамматический анализатор, разрешающий конфликты
на основе механизма приоритетов (раздел 5).
2. Входные и выходные файлы, структура грамматического ана-
лизатора
Входная информация для yacc задается в спецификационном
файле, структура которого рассматривается в разделе 4.
На выходе компилятора компиляторов в результате обра-
ботки спецификаций создается файл y.tab.c с исходным текстом
Си-процедур, составляющих грамматический анализатор. Основ-
ной в файле y.tab.c является процедура yyparse, реализующая
алгоритм грамматического разбора. При формировании ее yacc
использует файл /usr/lib/yaccpar, содержащий неизменяемую
часть анализатора. Кроме yyparse, в файл y.tab.c yacc вклю-
чает построенные им таблицы разбора, описания и программные
фрагменты пользовательских спецификаций.
- 4 -
Процедура yyparse представляет собой целочисленную
функцию, возвращающую значение 0 или 1. Значение 0 возвраща-
ется в случае успешного разбора по достижении признака конца
файла, значение 1- в случае несоответствия входного текста
заданным спецификациям. Процедура yyparse содержит многок-
ратное обращение к процедуре лексического анализа yylex,
текст которой либо переносится в файл y.tab.c из специфика-
ционного файла, либо прикомпоновывается впоследствии.
Для организации обращения к процедуре yyparse в библио-
теке yacc существует стандартная процедура main, не содержа-
щая помимо обращения к yyparse никаких действий. Пользова-
тель может написать собственную процедуру main, включив в
нее как начальные действия, предваряющие вызов yyparse
(установка нужных режимов, открытие файлов, частичное запол-
нение таблиц), так и действия по завершении разбора, которым
должен предшествовать анализ возвращаемого yyparse значения;
действиями в случае успешного разбора могут быть закрытие
файлов, вывод результатов, вызов следующей фазы транслятора,
в частности, повторный вызов yyparse. Для замены стандартной
процедуры пользовательской программой main она должна быть
описана в спецификационном файле или присоединена на этапе
вызова Си- компилятора для подготовки исполняемой программы.
Кроме выходного файла y.tab.c, yacc может дополнительно
генерировать следующие выходные файлы:
y.output
содержащий описание состояний анализатора и сообщения о
конфликтах (раздел 6)
y.tab.h
содержащий описание лексем (раздел 4.3).
Для генерации этих файлов требуется задание соответст-
вующих флагов при вызове yacc.
3. Процедура построения грамматического анализатора
Построение грамматического анализатора осуществляется в
два этапа. На первом этапе файл спецификаций входного языка
обрабатывается компилятором компиляторов yacc, для чего
задается командная строка
yacc [-vd] yfile
Здесь yfile - имя файла спецификаций, а флаги имеют следую-
щий смысл:
v - сформировать в файле y.output подробное описание грам-
матического анализатора;
- 5 -
d - сформировать в файле y.tab.h описание лексем. Тексто-
вые файлы y.output и y.tab.h содержат справочную инфор-
мацию для пользователя и никак не используются на вто-
ром этапе построения грамматического анализатора.
Основной результат работы yacc - процедура yyparse и
грамматические таблицы - помещается в файл y.tab.c. На вто-
ром этапе построения грамматического анализатора для получе-
ния в файле a.out исполняемой программы компилируется файл
y.tab.c и присоединяются другие программные компоненты:
cc y.tab.c [cfile...ofile...lfile...] -ly
cfile, ofile, lfile - имена исходных, объектных и библиотеч-
ных файлов, содержащих присоединяемые процедуры. В этот спи-
сок не включается имя стандартной библиотеки yacc
/lib/liby.a, ее подключение обеспечивается заданием флага
ly. Этот флаг полезно считать обязательным.
4. Задание входной информации yacc
4.1. Структура спецификационного файла
Пользовательские спецификации, задающие правила органи-
зации входной информации и алгоритм ее обработки, объединя-
ются в спецификационный файл следующей структуры:
%%
%%
Ядром спецификационного файла и единственной его обяза-
тельной частью является секция правил. При отсутсивии секции
программ может быть опущена вторая группа "%%"; следова-
тельно, минимальная допустимая конфигурация входного файла
имеет вид:
%%
Пробелы, знаки табуляции и перевода строки игнориру-
ются, недопустимо лишь появление их в именах. Комментарий,
ограниченный символами "/*" в начале и "*/" в конце, может
находиться между любыми двумя разделителями в любой секции
входного файла.
- 6 -
Секция правил состоит из одного или нескольких грамма-
тических правил. Эти правила должны определять все допусти-
мые входные конструкции и связанные с определенными конст-
рукциями действия по обработке входного потока.
Назначение секции деклараций состоит в основном в зада-
нии информации о лексемах.
Секция программ представляет собой некоторый набор про-
цедур на языке Си, которые должны включаться в текст прог-
раммы грамматического разбора. Например, это могут быть
процедура лексического анализа yylex и пользовательские про-
цедуры, вызываемые в действиях.
4.2. Секция правил
В данной секции с помощью набора грамматических правил
должны быть определены все конструкции, из которых впос-
ледствии будут строиться входные тексты. Не подлежат опреде-
лению в секции правил лишь конструкЦии, выбранные пользова-
телем в качестве лексем, считающиеся для грамматического
анализа исходными единицами. Правила задаются в форме, близ-
кой БНФ.
Правило, определяющее синтаксический вид конструкции,
задается таким образом:
<имя_нетерминального_символа>: определение;
Здесь ":" и ";" - специальные символы yacc. Правая часть
правила - определение - представляет собой упорядоченную
последовательность элементов (нетерминальных символов и лек-
сем), составляющих описываемую конструкцию. При грамматичес-
ком разборе такая последовательность в результате применения
правила заменяется нетерминальным символом, имя которого
указано в левой части. нетерминальные символы в определении
задаются именами, а лексемы - именами или литералами. Запись
имен и литералов совпадает с записью идентификаторов и сим-
вольных констант, принятой в Си.
Правило:
P_Head: P_name '(' P_list ')';
определяет нетерминал P_Head как последовательность 4-х эле-
ментов: два элемента заданы литерально, два других - име-
нами. По виду правила нельзя заключить, относятся эти имена
к лексемам или нетерминальным символам. yacc считает именами
нетерминалов все имена, не объявленные в секции деклараций
именами лексем (разд.4.3). Все нетерминалы должны быть
- 7 -
определены, т.е. имя каждого из них должно появиться в левой
части хотя бы одного правила. Допустимо задание нескольких
правил, определяющих один нетерминальный символ, т.е. правил
с одинаковой левой частью. Такие правила определяют конст-
рукции, идентичные на некотором уровне. Ниже приводятся три
правила, определяющие виды операторов в некотором языке:
statement : assign_stat ;
statement : if_then_stat;
statement : goto_stat;
Правила с общей левой частью можно задавать в сокращен-
ной записи, без повторения левой части, используя для разде-
ления альтернативных определений символ "|". Предыдущие пра-
вила можно переписать в виде:
statement : assign_stat |
if_then_stat |
goto_stat;
При необходимости с любым правилом можно связать дейст-
вие - набор операторов языка Си, которые будут выполняться
при каждом распознавании конструкции во входном тексте.
Действие не является обязательным элементом правил.
Действие заключается в фигурные скобки и помещается
вслед за правой частью правила, т.е. правило с действием
имеет вид:
<имя_нетерминального_символа>:
определение {действие};
Точка с запятой после правила с действием может опускаться.
При использовании сокращенной записи правил с общей
левой частью следует иметь в виду, что действие может отно-
ситься только к отдельному правилу, а не к их совокупности.
Следующий пример иллюстрирует задание действий в случае пра-
вил с общей левой частью.
statement: assign_stat
|
if_then_stat {printf("if_оператор\n");}
|
goto_stat {kgoto++;
printf("goto_оператор\n");}
- 8 -
На операторы, входящие в действия, не накладывается
никаких ограничений. В частности, в действиях могут содер-
жаться вызовы любых функций. Отдельные операторы могут быть
помечены, к ним возможен переход из других действий.
Существует возможность задания действий, которые будут
выполняться по мере распознавания отдельных фрагментов пра-
вила. Действие в этом случае помещается после одного из эле-
ментов правой части так, чтобы положение действия соотвест-
вовало моменту разбора, в который данному действию будет
передано управление.
Например, в правиле
if_then_stat: if'(' expression ')' {действие1}
then statement ';' {действие 2}
действия заданы с таким расчетом, чтобы при разборе строки
вида
if (a>b) then x=a;
действие 1 выполнялось при нахождении правой круглой скобки,
а действие 2 - по окончании разбора.
Для того, чтобы действия имели реальный смысл, они, как
правило, должны использовать некоторые общие переменные,
т.е. переменные, доступные во всех действиях и сохраняющие
свои значения по окончании очередного действия. Такие пере-
менные описываются в начале секции правил, все описание
ограничивается с двух сторон строками
%{
и
%}
Здесь же могут находиться произвольные операторы Си, расс-
матриваемые как общие действия для всех правил.
Дополним приведенный выше фрагмент спецификаций для
statement с тем, чтобы осуществлялся подсчет и вывод на
печать операторов goto
- 9 -
%{
int kgoto;
%}
prog: DECLS {kgoto=0;}
stats {printf("%d\n",kgoto);}
stats: statement
| stats statement;
statement:assign_stat
...
|
if_then_stat
...
|
goto_stat {kgoto++;
... }
Укажем еще на два вида объектов, использующихся в
действиях. Это, во-первых, глобальные переменные, которые
описываются в секции деклараций (разд.4.3), и, во-вторых,
специальные переменные (псевдопеременные),облегчающие взаи-
мосвязь между действиями и связь их с лексическим анализато-
ром. Работе с псевдопеременными посвящен раздел 4.5. Струк-
тура входной информации описывается в наборе правил иерархи-
чески, т.е. каждое правило соответствует определенному
уровню структурного разбиения. Однако, последовательность
задания правил может не отражать этой иерархии и быть вполне
произвольной. Единственно необходимой для yacc является
информация о том, какой из нетерминалов задает вершину
иерархии, т.е. соотвествует конструкциям, определяющим вход-
ной текст в целом. Этот нетерминал принято называть началь-
ным символом. Приведение входного текста к начальному сим-
волу является целью грамматического анализатора. По умолча-
нию yacc считает начальным символом тот нетерминал, имя
которого стоит в левой части первого из правил. Однако, если
определять начальный символ в первом правиле пользователю
неудобно, он может явно задать имя начального символа в сек-
ции деклараций.
Существует два специфических вида правил, на которые
полезно обратить внимание. Во-первых, это пустое правило
вида
<имя_нетерминального_символа>: ;
определяющее пустую последовательность символов. Сочетание
пустого правила с другими правилами, определяющими тот же
нетерминальный символ, является одним из способов указать на
необязательность вхождения соответствующей конструкции.
Например, совокупность правил
- 10 -
целое_число:знак целое_без_знака;
определяет возможность задания целых чисел со знаком и без
него. Другой способ описать эту возможность состоит в зада-
нии следующей группы правил:
целое_число:знак целое_без_знака |
целое_без_знака ;
знак: '+'|'-';
С пустым правилом может быть обычным образом связано
действие:
ИМЯ: {тело_действия} ;
Во-вторых, правила часто описывают некоторую конструкцию
рекурсивно, т.е. правая часть может рекурсивно включать
определяемый нетерминальный символ. Различают леворекурсив-
ные правила вида:
<имя_нетерминала>:<имя_нетерминала>
<многократно_повторяемый_фрагмент>;
и праворекурсивные вида
<имя_нетерминала>:
<многократно_повторяемый_фрагмент>
<имя_нетерминала>;
yacc допускает оба вида рекурсивных правил, однако при
использовании правил с правой рекурсией объем анализатора
увеличивается, а во время разбора возможно переполнение
внутреннего стека анализатора.
Рекурсивные правила необходимы при задании последова-
тельностей и списков. Следующие примеры иллюстрируют уни-
версальный способ описания этих конструкций:
последовательность: элемент
| последовательность элемент;
список: элемент|список ',' элемент;
- 11 -
Заметим, что в каждом из этих случаев первое правило (не
содержащее рекурсии) будет применено только для первого эле-
мента, а второе (рекурсивное) - для всех последующих. Нетер-
минальные символы, связанные с последовательностями или
списками разнородных элементов, могут описываться произволь-
ным числом рекурсивных и нерекурсивных правил. Например,
группа правил
идентификатор: буква |
'$' |
идентификатор буква|
идентификатор цифра|
идентификатор '_' ;
описывает идентификатор как последовательность букв, цифр и
символов "_", начинающуюся с буквы или символа "$". Следует
обратить внимание на то, что рекурсивные правила не имеют
смысла, если для определяемого ими нетерминала не задано ни
одного правила без рекурсии. Для обеспечения возможности
задания пустых списков или последовательностей в качестве
нерекурсивного правила используется пустое:
последовательность :
| последовательность элемент ;
Сочетание пустых и рекурсивных правил является удобным
способом представления грамматик и ведет к большей их общ-
ности, однако,некорректное использование пустых правил может
вызывать конфликтные ситуации (раздел 5) из-за неоднознач-
ности выбора нетерминала, соответствующего пустой последова-
тельности.
4.3. Секция деклараций
Секция деклараций состоит из последовательности строк
двух видов: строк-директив и строк исходного текста.
Строки исходного текста без изменений копируются в
выходной файл y.tab.c и могут содержать операторы препроцес-
сора и описание внешних объектов. Область действия перемен-
ных, описанных в секции деклараций, распространяется на весь
спецификационный файл, т.е. они доступны как в операторах
действий, так и в процедурах, находящихся в секции программ.
Строки-директивы начинаются символом "%" (этот символ в
yacc играет роль своего рода esc-символа). Две специальные
директивы
- 12 -
%{
и
%}
ограничивают с двух сторон группы строк исходного текста.
Остальные директивы служат для задания дополнительной инфор-
мации о грамматике.
5. Декларация имен лексем
%token <список_имен_лексем>
Пользователь при описании грамматики решает, какие
конструкции целесообразнее непосредственно выделять из вход-
ного текста на этапе лексического анализа, и на уровне этих
конструкций (лексем) задает грамматические правила. Все виды
лексем, кроме литералов, обозначаются некоторыми именами и
под этими именами фигурируют в секции правил. Благодаря дек-
ларации имен лексем в директиве %token yacc отличает имена
лексем от имен нетерминальных символов. Однако, декларация
ни в коей мере не обеспечивает распознавания лексем, и поль-
зователю рекомендуется считать для себя директиву %token
напоминанием о необходимости построения лексического анали-
затора (разд.4.4) и руководствоваться этой директивой при
его написании. Пример декларации имен лексем:
%token IDENT CONST ЗНАК IF THEN GOTO
Заметим, что ключевые слова описываемого входного языка
часто бывает удобно считать лексемами. Имена лексем могут
совпадать с этими ключевыми словами, недопустимым является
лишь совпадение имен лексем с зарезервированными словами
языка Си. В примере во избежание недоразумений для имен лек-
сем использованы прописные буквы.
6. Декларация приоритетов и ассоциативности лексем
%left <список_лексем>
%right <список_лексем>
%nonassoc <список_лексем>
Лексемы в данных директивах задаются литералами или
именами. В последнем случае декларация приоритета заменяет
также декларацию имени лексемы, хотя в целях обеспечения
наглядности описания является желательным присутствие в
- 13 -
списке директивы %token всего набора имен лексем.
Содержательный смысл декларации приоритетов и ассоциа-
тивности выясняется в разделе 5 в связи с вопросом о разре-
шении конфликтов грамматического разбора. Использование
лексемы само по себе не требует задания ее приоритета или
ассоциативности.
При первом появлении лексемы или литерала в секции дек-
лараций за каждым из них может следовать неотрицательное
целое число, рассматриваемое как номер типа лексемы. По
умолчанию номера типов всех лексеМ определяются yacc следую-
щим образом:
- для литерала номером типа лексемы считается числовое
значение данного литерального символа, рассматриваемого
как однобайтовое целое число;
- лексемы,обозначенные именами, в соответствии с очеред-
ностью их объявления получают последовательные номера,
начиная с 257;
- специальная лексема error, зарезервированная для обра-
ботки ошибок (раздел 7), получает номер типа 256.
Для каждого имени лексемы независимо от того, переопре-
делен ли ее номер пользователем, yacc генерирует в выходном
файле y.tab.c оператор макропрепроцессора
#define <имя_лексемы> <номер_типа>
В случае переопределения номера типа литеральной лек-
семы также формируется оператор #define, например, директива
%left 'z' 258
породит оператор
#define z 258
Заметим, что возможно переопределение номеров лишь для
буквенных литералов.
При вызове yacc с флагом -d последовательность операто-
ров #define помещается также в информационный файл y.tab.h.
Переопределив при необходимости ряд номеров типов
лексем,пользователь должен проверить уникальность номеров у
всех используемых лексем.
- 14 -
7. Декларация имени начального символа
%start <имя_начального_символа>
Директива отменяет действующий по умолчанию выбор в
качестве начального символа нетериминала, определяемого пер-
вым грамматическим правилом.
7.1. Секция программ
В секцию программ помещается описание пользовательских
процедур, которые должны быть включены в генерируемую прог-
рамму грамматического анализа. Любая из определяемых пользо-
вателем программных компонент может находиться в секции
программ спецификационного файла, либо присоединяться на
этапе вызова Си-компилятора для трансляции файла y.tab.c и
компоновки выходной программы. Перечислим процедуры, которые
одним из этих способов должны быть заданы:
- лексический анализатор - функция с именем yylex();
- все процедуры, вызовы которых содержатся в действиях,
связанных с грамматическими правилами;
- главная процедура main() при необходимости заменить ее
стандартный библиотечный вариант, который имеет вид
main() {return (yyparse();}
- процедура обработки ошибок yyerror() - также для замены
библиотечного варианта (его текст приводится ниже).
#include <stdio.h>
yyerror(s) char *s; {
fprintf(stderr, "%s\n", s);}
Для обеспечения корректной работы грамматического ана-
лизатора функция лексического анализа yylex должна быть сог-
ласована с конкретной спецификацией грамматики и удовлетво-
рять определенным требованиям. Основная задача функции yylex
состоит во вводе из входного потока ряда очередных символов
до выявления конструкции, соответствующей одной из лексем, и
возвращении номера типа этой лексемы. Для нелитеральных лек-
сем номером типа может служить объявленное в секции деклара-
ций имя лексемы (с помощью механизма #define yacc обеспечи-
вает замену его нужным номером), в случае литералов номером
типа является числовое значение символа (если оно не было
- 15 -
переопределено). Алгоритм поиска должен заключаться в
попытке нахождения сначала более сложных (нелитеральных)
лексем и лишь при несовпадении ни с одной из них текущих
элементов ввода возвращать номер типа литеральной лексемы
(любой однозначный символ, не начинающий ни одну из возмож-
ных лексем, сам образует лексему).
Приведем текст процедуры лексического анализа, распоз-
нающей идентификаторы и целые числа:
#include <stdio.h>
yylex() {char c;
while ((c=getc(stdin))==' '||c=='\n');
if(c>='0'&&c<='9'){
while((c=getc(stdin))>='0'&&c<='9');
ungetc(c,stdin));
return (CONST);}
if (c>='a'&&c<='z'){
while ((c=getc(stdin))>'a'&&c<='z'
||c>='0'&&c<='9');
ungetc(c,stdin); return (NAME);}
return (c); }
Сложность лексического анализатора зависит от того,
какие структурные единицы взяты за основу при описании грам-
матических правил. Детализовав грамматику до отдельных сим-
волов, можно обойтись простейшим лексическим анализатором,
осуществляющим только их ввод:
yylex() {return (getchar());}
Однако, в этом случае число правил растет, а граммати-
ческий разбор оказывается менее эффективным. Поэтому пользо-
ватель обычно должен найти некоторый компромисс при выборе
набора лексем.
В процедуре лексического анализа кроме выделения лексем
можно предусмотреть некоторую обработку лексем определенных
типов, в частности, запоминание конкретных значений лексем.
Кроме того, эти значения обычно требуется передать граммати-
ческому анализатору. С этой целью нужное значение должно
быть присвоено внешней переменной целого типа с именем yyl-
val. Если функция yylex находится в отдельном файле, то эта
переменная должна быть объявлена:
extern int yylval;
- 16 -
Уточним, что в дальнейшем значением лексемы мы будем
называть значение, присвоенное при ее распознавании перемен-
ной yylval; значение, возвращаемое функцией yylex, является
номером типа лексемы. Примером значения лексемы могут слуить
числовое значение цифры, вычисленное значение константы,
адрес идентификатора в таблице имен (построение таблицы имен
удобно осуществлять лексическим анализатором). Заметим,
что, хотя значение yylval устанавливается с целью использо-
вания его в действиях, непосредственное обращение к переМен-
ной yylval в действии не имеет смысла (поскольку в yylval
всегда находится значение последней выделенной лексемы).
Доступ в действиях к значениям лексем осуществляется с
помощью специального механизма, описанного в разделе 4.5.
7.2. Действия с использованием псевдопеременных
Для обеспечения связи между действиями, а также между
действиями и лексическим анализатором создаваемые yacc грам-
матические анализаторы поддерживают специальный стек, в
котором сохраняются значения лексем и нетерминальных симво-
лов. Значение лексемы автоматически попадает в стек после
ее распознавания лексическим анализатором (напомним, что им
считается текущее значение переменной yylval). После каждой
свертки вычисляется значение нетерминала, заместившего свер-
нутую строку, и помещается в вершину стека; значения элемен-
тов правой части примененного правила перед этим выталкива-
ются из стека. Заметим, что таким образом к моменту свертки
любого правила все значения нетерминалов в правой части ока-
зываются вычисленными в результате сверток. Способ вычисле-
ния значения нетерминала будет рассмотрен ниже.
Описанный механизм не требует вмешательства пользова-
теля и предоставляет ему следующие возможности:
- Использовать в действиях, осуществляемых после свертки
по правилу, значение любого элемента его правой части.
Доступ к этим значениям обеспечивается набором так
называемых псевдопеременных с именами $1,$2,..., где $i
соответствует значению i-го элемента; элементы правой
части правила нумеруются слева направо без различия
лексем и нетерминальных символов, например, в правиле
P_Head: P_name '(' P_list ')';
псевдопеременные $1,$2,$3,$4 относились бы соответст-
венно к P_name, '(', P_list, ')'.
- Формировать в действиях значение, образованного в
результате свертки нетерминала путем присвоения этого
значения псевдопеременной с именем $$. Так, в правиле
- 17 -
expr: expr '+' expr { $$=$1+$3; }
значением нового нетерминала expr станет сумма ранее
вычисленных значений двух других нетерминалов expr.
Eсли в действии не определяется значение переменной $$
(а также если действие отсутствует), значением нетерми-
нала после свертки по умолчанию становится значение
первого элемента правой части, т.е. неявно выполняется
присваивание
$$=$1;
Пример (вычисление значения целого числа)
%token DIGIT
%%
...
CONST: DIGIT
| CONST DIGIT {$$=$1*10+$2;}
...
%%
yylex()
{
char c;
if((c=getchar())>='0'&& c<='9') {
yylval = c-'0';
return (DIGIT);
}
...
}
Здесь при свертке по первому правилу нетерминал CONST
получает значение первой цифры, присвоенное в функции
yylex переменной yylval; при каждой свертке по второму
правилу явно вычисляется значение нового нетерминала
CONST.
Несколько иная ситуация в отношении использования псев-
допеременных имеет место для правил, содержащих действия
внутри правой части. На самом деле yacc интерпретирует пра-
вило вида
A: B C {действие 1} D {действие 2}
K {действие 3}
как
A: B C EMPTY1 D EMPTY2 K;
и в месте, где вставлено действие, при разборе
- 18 -
осуществляется свертка по пустому правилу, сопровождающаяся
выполнением указанного действия. При этом независимо от
характера действия очередной элемент в стеке значений отво-
дится для хранения значения неявно присутствующего "пустого"
нетерминала. В действии, находящемся в конце правила, согла-
шение о значениях псевдопеременных остается прежним, если
иметь в виду наличие дополнительных символов. В приведенном
выше правиле в действии 3 для доступа к значениям элементов
B, C, D, K следовало бы использовать соответственно псевдо-
переменные $1, $2, $4, $6; псевдоперемнные $3, $5 хранят
результаты действий 1 и 2. В действиях, находящихся внутри
правила, с помощью псевдоперемнных $i доступны значения рас-
положенных левее элементов, а также результаты предшествую-
щих вставленных в тело действий. Результатом внутреннего
действия (т.е. значением неявного нетерминала) является зна-
чение, присвоенное в этом действии псевдопеременной $$, при
отсутствии такого присваивания результат действия не опреде-
лен. Заметим, что присваивание значения псевдопеременной $$
во внутренних действиях не вызывает предварительной уста-
новки значения нетерминала, стоящего в левой части правила:
это значение в любом случае устанавливется только действием
в конце правила или считается равным значению $1.
В нашем примере в действии 1 доступными являются только
значения элементов B и C (им соответствуют псевдопеременные
$1 и $2), а в действии 2 - значения элементов B, C, D и
результат действия 1 с помощью псевдопеременных $1, $2, $4,
$3.
Следующий пример иллюстрирует варианты использования
псевдопеременных:
%token ИМЯ КЛЮЧ1 КЛЮЧ2 КОНЕЦ
. . .
%%
входной_поток: данные КОНЕЦ
{printf("Данные занесены в файл %s\n",$1);};
данные:
ИМЯ {abc = creat($1,0666);}
КЛЮЧ1 КЛЮЧ2 {option($3,$4);}
упр_строка '\n' {converse(0,$5,$6);
write($1,$6,80);}
текст {converse(1,$5,$8);
write($1,$6,$8);
close($1);};
упр_строка: ...
текст : ...
. . .
- 19 -
Управляющая строка и текст преобразуются в соответствии с
заданными ключами и записываются в файл с указанным именем.
Значением нетерминала данные в результате неявного действия
становится значение лексемы ИМЯ (адрес строки с именем файла
присваивается в лексическом анализаторе переменной yylval).
8. Конфликты грамматического разбора
Заданная грамматика является неоднозначной, если
существует входная строка, которая в соответствии с этой
грамматикой может быть разобрана двумя или более различными
способами. Рассмотрим, например, набор правил, описывающих
константное арифметическое выражение:
expr: CONST /*1*/
|
expr '+'expr /*2*/
|
expr '-'expr /*3*/
|
expr '*'expr /*4*/
|
expr '/'expr; /*5*/
Описывая возможность построения выражения из двух выра-
жений, соединенных знаком арифметической операции, правила
неоднозначно определяют путь разбора некоторых входных
строк. Так, строка вида:
expr*expr-expr
допускает два пути разбора, приводящих к различным группи-
ровкам ее элементов:
expr*(expr-expr) и (expr*expr) - expr
С точки зрения работы грамматического анализатора дан-
ная ситуация проявляется в неоднозначности выбора действия
при вводе лексемы "-" в момент, когда разобранная часть
строки приведена к виду expr*expr. Два возможных действия
анализатора состоят в следующем:
Можно ввести следующий символ и без применения правила
подстановки перейти в новое состояние. В разделе 1 мы
назвали такое действие сдвигом. Выбор сдвига приведет к
тому, что в одном из следующих состояний ко второй
части конструкции для приведения ее к expr будет приме-
нено правило (3), а затем вся полученная конструкция
сведется к expr применением правила (4).
- 20 -
Можно сразу применить к конструкции expr*expr правило
(4), тем самым приведя ее к expr, и без ввода нового
символа перейти в очередное состояние. Такое действие в
разделе 1 было названо сверткой. Использование свертки
в данном состоянии приведет к применению в дальнейшем
правила (3) для свертывания оставшейся части конструк-
ции в expr.
Неоднозначность такого рода будем называть конфликтом
"сдвиг/свертка". (Выше этот конфликт был умышленно показан
на примере выражения, порядок разбора которого существен в
связи с различием приоритетов операций. На самом деле конф-
ликт сдвиг/свертка возникает и при разборе такой строки, как
expr-expr-expr. В этом случае разница в разборе ведет лишь
к трактовке операции "-" как лево- или правоассоциативной.
Однако, как известно, ассоциативность иногда играет важную
роль, например, для операций присваивания, возведения в сте-
пень. Возможен другой вид конфликта, состоящий в выборе
между двумя возможными свертками; будем называть его конф-
ликтом "свертка/свертка". Для примера подобного конфликта
приведем грамматику, задающую десятичную и шестнадцатеричную
форму записи константы:
const: const_10 /*1*/
| const_16 ; /*2*/
const_10: dec_sequence; /*3*/
const_16: hex_sequence 'x'; /*4*/
dec_sequence:digit /*5*/
| dec_sequence digit; /*6*/
hex_sequence:digit /*7*/
| ABCDEF /*8*/
|hex_sequence digit /*9*/
|hex_sequence ABCDEF; /*10*/
ABCDEF : 'A'|'B'|'C'|'D'|'E'|'F';
digit:'0'|'1'|'2'|'3'|'4'|'5'|'6'
|'7'|'8'|'9';
При появлении на входе первой же десятичной цифры (если
с нее начинается последовательность) после ее замены нетер-
миналом digit возникает конфликт между двумя возможными
свертками: к нетерминалу dec_sequence в результате примене-
ния правила (5) и к нетерминалу hex_sequence с помощью пра-
вила (7). Заметим, что эта грамматика, в отличиe от грамма-
тики в предыдущем примере, не позволяет корректно разобрать
какую-либо строку двумя способами и в принципе нетерминал
const определен однозначно. Однако, алгоритм разбора с
просмотром вперед на 1 символ не в состоянии правильно осу-
ществить выбор нужного правила. Следовательно, в этом случае
речь идет о неоднозначности грамматики по отношению к приня-
тому в yacc методу разбора. Поскольку вопрос о принципиаль-
ной неоднозначности грамматики формально неразрешим, будем в
дальнейшем понимать под неоднозначностью невозможность для
- 21 -
анализатора в некоторые моменты разбора выбрать очередное
действие. Каждая ситуация (т.е. появление в некотором состо-
янии некоторой входной лексемы), которая при разборе спо-
собна вызвать конфликт "сдвиг/свертка" или "свертка/
свертка", выявляется yacc уже на этапе построения граммати-
ческого анализатора. При этом yacc выдает сообщение о числе
выявленных конфликтных ситуаций обоих видов, а в выходной
файл y.output (если он формируется) помещается подробное
описание всех конфликтов. Однако, yacc не считает наличие
конфликтов фатальной ошибкой грамматики и строит граммати-
ческий анализатор, заранее разрешая все возможные конфликты
путем выбора в каждой ситуации единственного действия.
При работе yacc используются два способа разрешения
конфликтов. Первый способ действует по умолчанию (т.е. при
отсутствии специальной пользовательской информации) и заклю-
чается в применении следующих двух правил для выбора дейст-
вия в конфликтных ситуациях:
В случае конфликта сдвиг/свертка по умолчанию делается
сдвиг.
В случае конфликта свертка/свертка по умолчанию дела-
ется свертка по тому из конкурирующих правил, которое
задано первым в спецификационном файле.
Грамматический анализатор, построенный с использованием
этих правил, может не обеспечивать "правильного" с точки
зрения пользовательской грамматики разбора. В частности,
для первого из приведенных выше примеров разбор заключался
бы в сворачивании арифметических выражений справа налево без
учета приоритетов операций. Во втором примере в результате
замены первой конструкции digit нетерминалом dec_sequence
все числа, начинающиеся с цифры, разбирались бы как десятич-
ные, а появление одной из букв от A до F или символа "x" в
конце числа неверно трактовалось как ошибка во входном
тексте.
Однако, в ряде ситуаций описанный способ разрешения
конфликтов приводит к нужному результату. Например, рассмот-
рим фрагмент грамматики языка программирования, описывающий
условный оператор:
оператор: if '(' условие ')' оператор /*1*/
|
if '(' условие ')' оператор else
оператор; /*2*/
Входная строка вида:
if(C1) if(C2) S1 else S2
вызвала бы при разборе конфликт сдвиг/свертка в момент
- 22 -
просмотра символа else. Введенная часть строки к этому вре-
мени имеет вид:
if (условие) if (условие) оператор
Если выполнить свертку второй части конструкции по правилу
(1), то строка сведется к:
if (условие) оператор
(Заметим, что применить еще раз правило(1) мешает просмот-
ренный заранее символ else). После ввода конструкции S2 и
замены ее нетерминалом оператор к строке:
if (условие) оператор else оператор
будет применено правило (2). Полученный разбор соответствует
следующей интерпретации входной строки:
if (C1) {if(C2) S1} else S2
При альтернативном подходе в случае применения сдвига в
момент появления else входная строка была бы введена пол-
ностью:
if (условие) if (условие) оператор
else оператор
Ко второй части строки можно применить правило (2), а затем
свернуть полученную конструкцию:
if (условие) оператор
по правилу (1). Такой разбор соответствует второй возможной
интерпретации входной строки:
if (C1) {if(C2) S1 else S2}
Как известно, в большинстве языков программирования принята
именно эта интерпретация (каждый else относится к ближайшему
предшествующему if). Значит, выбор сдвига, осуществляемый по
умолчанию, для данной грамматики верен.
В качестве рекомендации отметим,что применение принципа
умолчания для конфликтов сдвиг/свертка приводит к положи-
тельному результату, если в грамматике принята правоассоциа-
тивная интерпретация соответствующих конструкций и для них
отсутствует понятие приоритета. Что касается конфликтов
свертка/свертка, то стандартный способ их разрешения оказы-
вается полезным только тогда, когда при любых конфликтах
между данными двумя правилами справедлив выбор одного и того
же правила.
- 23 -
В любом случае, если yacc сообщил о наличии конфликтных
ситуаций, пользователь должен тщательно проанализировать
содержательный смысл каждого конфликта и правильность выб-
ранного yacc действия. Вся необходимая для этого информация
содержится в файле y.output, структура которого будет расс-
мотрена ниже. Если оказалось, что конфликты разрешены неу-
довлетворительно, то грамматика должна быть перестроена или
уточнена пользователем. В случае конфликтов свертка/свертка
всегда требуется изменение самих грамматических правил; для
конфликтов сдвиг/свертка есть возможность без перестройки
правил уточнить грамматику путем задания информации о прио-
ритетах и ассоциативности лексем и правил.
В качестве примеров устранения конфликтов путем измене-
ния правил приведем перестроенные варианты рассматривавшихся
выше грамматик. Поскольку исходные конфликтные грамматики
полностью удовлетворяют требованиям генерируемых ими языков,
но содержат недостаточно информации для однозначного раз-
бора, перестройка правил носит уточняющий характер.
Перестроенная грамматика константного арифметического
выражения:
expr: expr1
|
expr '+' expr1
|
expr '-' expr1;
expr1: CONST
|
expr1 '*' CONST
|
expr1 '/' CONST;
Ниже будет приведен также вариант грамматики, полученной из
исходной введением приоритетов (без перестройки правил).
Перестроенная грамматика для задания константы:
const: const_10
| const_16;
const_10: dec_sequence ;
const_16: hex_sequence 'x'
| dec_sequence 'x';
dec_sequence: digit
| dec_sequence digit;
hex_sequence: ABCDEF
| dec_sequence ABCDEF
| hex_sequence ABCDEF
|hex_sequence dec_sequence;
ABCDEF:...
digit:...
- 24 -
Рассмотрим теперь второй из используемых yacc способов раз-
решения конфликтов, базирующийся на задании пользователем
информации о приоритетах и ассоциативности. Отметим предва-
рительно две основные причины конфликтности грамматик:
принципиальная невозможность задать генерируемый язык
бесконфликтной грамматикой;
недостаточность информации для построения однозначного
грамматического разбора.
Грамматики, конфликтные по второй причине, всегда
допускают преобразование правил до полного устранения конф-
ликтов; в случае конфликтов сдвиг/свертка yacc всегда может
построить для этих грамматик корректный разбор путем разре-
шения конфликтов. Для грамматик, конфликтных по причине 1,
попытки разрешения конфликтов не приведут к нужному резуль-
тату. Однако, надо убедиться в том, что конфликтная грамма-
тика действительно отражает входной язык: возможно, конф-
ликты не имеют отношения к этому языку, а вызваны неодноз-
начностью другого, реально описанного языка. Вообще, конф-
ликты стоит рассматривать как повод проверить грамматику на
соответствие языку (хотя последнее не гарантируется и
отсутствием конфликтов). Задание приоритетов для неверной
грамматики не приведет к генерации нужного языка, но может
замаскировать ошибки, сняв вопрос о конфликтах.
Приоритетное разрешение конфликтов сдвиг/свертка сос-
тоит в том, что с обоими действиями yacc ассоциирует приори-
теты (со сдвигом - приоритет лексемы, чтение которой вызы-
вает данный конфликт, со сверткой - приоритет конкурирующего
правила) и выбирает более приоритетное действие. В случае
равенства приоритетов yacc руководствуется при выборе
свойством ассоциативности. Приоритеты и ассоциативность
отдельных лексем (явно) и правил (явно и неявно) задаются
пользователем, все остальные приоритеты считаются неизвест-
ными. yacc использует для разрешения конфликта данный спо-
соб, если известны приоритеты обоих конкурирующих действий.
Поэтому для разрешения ряда конфликтов на приоритетной
основе необходимо установить приоритеты участвующих в них
лексем и правил.
Следует понимать,что задание приоритетов не ведет к
устранению конфликтов и не делает грамматику однозначной. Но
в отличие от конфликтов, разрешаемых yacc по принципу умол-
чания, пользователь получает здесь возможность управлять
разрешением конфликтов. yacc, сообщая общее число конфлик-
тов, не учитывает в нем конфликтов, разрешенных в соответст-
вии с информацией о приоритетах и не включает в выходной
файл y.output описания этих конфликтов.
Приоритеты и ассоциативность лексем задаются в секции
деклараций с помощью директив трех видов:
- 25 -
%left <список_лексем>
%right <список_лексем>
%nonassoc <список_лексем>
Каждая директива приписывает всем перечисленным в списке
лексемам одинаковый приоритет. Директивы %left и %right
одновременно задают соответственно левую или правую ассоциа-
тивность лексем. Директива %nonassoc говорит об отсутствии
у перечисленных лексем свойства ассоциативности. Устанавли-
ваемый директивами приоритет не имеет численного выражения,
а его относительное значение возрастает сверху вниз.
Пример задания приоритетов лексем:
%token OR NOR XOR AND NAND
%right '='
%left OR NOR XOR
%left AND NAND
%left '+' '-'
%left '*' '/'
/* самый низкий приоритет имеет лексема "=",
самый высокий - лексемы "*" и "/"
*/
Приоритет правила автоматически определяется приорите-
том последней лексемы в теле правила. Если в секции деклара-
ций для этой лексемы не задан приоритет или если правая
часть правила вообще не содержит лексем, то приоритет пра-
вила не определен. Этот принцип можно отменить явным зада-
нием приоритета правила равным приоритету любой (имеющей
приоритет) лексемы с помощью директивы:
%prec <лексема>
помещенной вслед за правой частью правила (перед точкой с
запятой или действием). Например, правилу:
expr: '-' expr %prec '*';
директива %prec придает приоритет лексемы "*" (лексема "-"
при задании грамматики выражений часто используется для
обозначения унарной и бинарной операций, имеющих разный при-
оритет; с помощью директивЫ %prec унарной операции можно
приписать более высокий приоритет. Иногда, чтобы связать с
правилом приоритет, не совпадающий с приоритетом ни одной
лексемы, вводят псевдолексему, задав ей в секции деклараций
уникальный приоритет, и приписывают приоритет псевдолексемы
правилу. В примере грамматики настольного калькулятора, при-
водимом в приложении, с операцией "унарный минус" связан
приоритет псевдолексемы UMINUS).
- 26 -
Сформулируем теперь полностью используемые yacc правила
разрешения конфликтов сдвиг/свертка на основе информации о
приоритетах и ассоциативности (напомним, что конфликты
свертка/свертка разрешаются только по принципу умолчания):
Если для входной лексемы и правила заданы приоритеты и
эти приоритеты различны, то выбирается действие с боль-
шим приоритетом. Больший приоритет правила вызывает
свертку по нему, больший приоритет лексемы вызывает
сдвиг.
Если приоритеты заданы и совпадают, то принимается во
внимание заданная одновременно с приоритетом ассоциа-
тивность: в случае левой ассоциативности используется
свертка, в случае правой - сдвиг. Отсутствие свойства
ассоциативности (директива %nonassoc) в данном случае
указывает на ошибку во входном тексте и анализатор
воспримет вызвавшую данный конфликт лексему как ошибоч-
ную.
Если не задан приоритет входной лексемы и/или приоритет
правила, то действует принцип разрешения конфликтов по
умолчанию, в результате чего выбирается сдвиг.
Пример грамматики константного выражения, уточненной зада-
нием приоритетов:
%left '+' '-'
%left '*' '/'
%%
expr: CONST
| expr '+' expr
| expr '-' expr
| expr '*' expr
| expr '/' expr;
9. Структура информационного входного файла y.output
Основную часть данного файла составляет описание состо-
яний построенного грамматического анализатора. Информация о
каждом состоянии приводится в следующем порядке:
- Перечень соответствующих данному состоянию конфигураций
грамматики (конфигурация характеризуется определенным
грамматическим правилом и позицией в его правой части,
достигнутой к данному моменту разбора). Каждая конфигу-
рация представляется правилом с отмеченной с помощью
символа подчеркивания "_" распознанной частью (позицией
конфигурации). Например, конфигурация:
expr: expr +_expr
- 27 -
соответствует распознанной при разборе строки по ука-
занному правилу последовательности символов expr+.
- Действия анализатора при вводе в качестве очередного
просматриваемого символа каждой из лексем. Различные
виды действий указываются следующим образом:
<лексема> сдвиг <номер_состояния> -
сдвиг при вводе данной лексемы в состояние с указанным
номером;
<лексема> свертка <номер_правила> -
свертка при вводе лексемы по правилу с указанным номе-
ром;
<лексема> error -
выдача сообщения об ошибке во входных данных ("синтак-
сическая ошибка") и возврат из процедуры грамматичес-
кого анализа с кодом 1 (дальнейший разбор невозможен);
<лексема> accept -
возврат из процедуры грамматического анализа с кодом 0
(успешное завершение разбора). Последняя из строк,
описывающих действия анализатора, содержит вместо ука-
зания лексемы символ "." и сообщает действие, выполняе-
мое анализатором для всех лексем, не перечисленных в
данном состоянии. Часто эта строка имеет вид:
. error
и указывает, что все перечисленные лексемы в данном
состоянии являются недопустимыми.
- Перечень переходов для данного состояния. Каждый пере-
ход задается строкой
<имя_терминала> переход <номер_состояния>
сообщающей, в какое состояние перейдет анализатор после
свертки указанного нетерминала, если его распознавание
было начато из данного состояния.
Кроме того, описанию состояния может предшествовать
информация о конфликтах обнаруженных yacc для этого состоя-
ния и разрешенных по принципу умолчания. Информация о конф-
ликте содержит тип конфликта (св/св или сдв/св), конкурирую-
щие действия анализатора (при этом для сдвига указывается
номер состояния, для свертки - номер правила) и лексему, при
появлении которой возникает данный конфликт. Узнать, какое
- 28 -
из возможных действий будет выполнено анализатором, можно из
описания самого состояния.
Пример описания состояния:
8:Конфликт сдв/св (сдвиг 5,свертка 2) при +
Состояние 8
a:a_+a
a:a+a_ (2)
+ сдвиг 5
. свертка 2
Состоянию 8 здесь соответствуют две различные позиции, дос-
тигнутые при разборе по правилу
a: a '+' a
Kонфликт между сверткой по этому правилу и сдвигом в состоя-
ние 5 при вводе лексемы "+" разрешен в пользу сдвига. Ввод
остальных лексем вызывает свертку.
После описания состояния возможен ряд сообщений о нес-
вернутых правилах (с указанием этих правил), т.е. о прави-
лах, свертка по которым не будет произведена ни в одном из
состояний. Наличие таких правил с большой вероятностью сви-
детельствует о некорректности грамматики.
В конце файла приводится информация статистического
характера о реальном и предельном количестве терминальных и
нетерминальных символов, грамматических правил и состояний.
Фиксируется число конфликтов каждого типа, число различных
действий грамматического анализатора, занимаемый им объем
памяти, приводятся данные об использовании внутренних струк-
тур данных (множеств).
10. Обработка ошибок при грамматическом разборе
Если входной поток не удовлетворяет заданной грамма-
тике, то грамматический анализатор в момент ввода лексемы,
делающей невозможным продолжение разбора, фиксирует ошибку.
Эту лексему мы в дальшейшем будем называть ошибочной лексе-
мой. Реально ошибка может быть вызвана не только неверными
входными данными, но и некорректностью самого грамматичес-
кого анализатора, являющейся следствием некорректной грамма-
тики.
Стандартной реакцией грамматического анализатора на
ошибку является выдача сообщения ("синтаксическая ошибка") и
прекращение разбора. Эту реакцию можно несколько изменить,
например, сделать сообщение об ошибке несколько более инфор-
мативным, задав собственную процедуру yyerror. Однако, наи-
более важная задача состоит в том, чтобы заставить анализа-
тор в этом случае продолжать просмотр входного потока, в
- 29 -
частности, для выявления остальных ошибок. Применяемый yacc
механизм восстановления основан на чтении и отбрасывании
некоторого числа входных лексем; от пользователя требуется
введение дополнительных грамматичсеких правил, указывающих,
в каких конструкциях синтаксические ошибки являются допусти-
мыми (в отношении возможности восстановления). Одновременно
эти правила определяют путь дальнейшего разбора для ошибоч-
ных ситуаций. Для указания точек допустимых ошибок исполь-
зуется зарезервированное с этой целью имя лексемы error.
Пример:
a: b c d ; /*1*/
a: b c error; /*2*/
d: d1 d2 d3; /*3*/
Второе правило указывает путь разбора в случае, если при
распознавании нетерминала a встретится ошибка после выделе-
ния элементов b и c.
yacc обрабатывает правила, содержащие лексему error,
так же, как все остальные правила. В результате в ряде сос-
тояний построенного анализатора оказывается предусмотренным
действие для лексемы error (отличное от действия error).
Будем говорить, что в этих состояниях лексема error допус-
тима. Рассмотрим порядок работы анализатора при появлении
во входном потоке ошибочной лексемы (т.е. лексемы, ввод
которой в данном состоянии вызывает действие error):
Фиксируется состояние ошибки; вызывается функция yyer-
ror для выдачи сообщения.
Путем обратного просмотра пройденных состояний,начиная
с данного, делается попытка найти состояние, в котором
допустима лексема error. Отсутствие такого состояния
говорит о невозможности восстановления, и разбор прек-
ращается.
Осуществляется возврат в найденное состояние (кроме
случая, когда им является непосредственно то состояние,
в котором встретилась ошибка)
Выполняется действие, заданное в этом состоянии для
лексемы error. Очередной входной лексемой становится
лексема, вызвавшая ошибку.
Разбор продолжается, но анализатор остается в состоянии
ошибки до тех пор, пока не будут успешно прочитаны и
обработаны три подряд идущие лексемы. При нахождении
анализатора в состоянии ошибки отличие в обработке оши-
бочной лексемы заключается в том, что сообщения об
ошибке не выдается, а сама лексема игнорируется.
- 30 -
После обработки трех допустимых лексем считается, что
восстановление произошло, и анализатор выходит из сос-
тояния ошибки.
Итак, грамматический анализатор, встретив ошибку, пыта-
ется найти ближайшую точку во входном потоке, где разрешена
лексема error. При этом сначала делается попытка возврата в
рамках правила, по которому шел разбор в момент появления
ошибочноЙ лексемы, затем поиск распространяется на правила
все более высокого уровня. В примере, приведенном в начале
раздела, ввод недопустимой лексемы после того, как прочитана
строка b c d1 d2 вызовет возврат к состоянию, характеризую-
щемуся конфигурациями:
a: b c_d;
a: b c_error;
и продолжение разбора по правилу (2).
Часто правила, учитывающие возможность ошибки, задаются
на уровне основных структурных единиц входного текста. Нап-
ример, для пропуска в тексте ошибочных операторов может быть
использовано правило
оператор: error;
При этом восстановление из состояния ошибки произойдет после
нахождения трех лексем, которые могут следовать после опера-
тора, например, начинать новый оператор. Если точно распоз-
нать начало оператора невозможно, то ошибочное состояние
может быть подавлено преждевременно, а обработка нового опе-
ратора начата с середины ошибочного, что, вероятно, приведет
к повторному сообщению об ошибке (на самом деле не существу-
ющей). Учитывая это, более надежного результата следует ожи-
дать от правил вида:
оператор: error ';'
Здесь восстановление произойдет только после нахождения ";"
и двух начальных лексем следующего оператора; все лексемы
после найденной ошибочной до ";" будут отброшены.
С правилами, включающими лексему error, могут быть свя-
заны действия. С их помощью пользователь может самостоя-
тельно обработать ошибочную ситуацию. Кроме обычных операто-
ров, здесь можно использовать специальные операторы yyerror
и yyclearin, которые yacc на макроуровне расширяет в нужные
последовательности. Оператор yyerror аннулирует состояние
ошибки. Таким образом, можно отменить действие принципа
"трех лексем". Это помогает предотвратить маскирование новых
ошибок в случаях, когда конец ошибочной конструкции распоз-
нается самим пользователем или однозначно определяется в
правиле по меньшему числу лексем.
- 31 -
Оператор yyclearin стирает хранимую анализатором пос-
леднюю входную лексему, если поиск нужной точки для возоб-
новления ввода обеспечивается в заданном пользователем
действии.
Приведем общую форму правила с восстановительным дейст-
вием
оператор : error {resynch();
yyclearin;
yyerror;}
Предполагается, что пользовательская процедура resynch()
просматривает входной поток до начала очередного оператора.
Вызвавшая ошибку лексема, хранимая анализатором в качестве
входной лексемы, стирается, после этого гасится состояние
ошибки.
При построении анализаторов, работающих в интерактивном
режиме, для обработки ошибок рекомендуются правила вида:
входная_строка : error '\n' {yyerrok;
printf("Повторите последнюю строку \n");}
входная_строка {$$=$4;}
В действии, предусмотренном после ввода ошибочной строки,
пользователю делается подсказка, а состояние ошибки гасится.
Значением нетерминала после свертки здесь становится значе-
ние повторно введенной строки.
11. Диагностика ошибок
yacc выдает ряд сообщений об ошибках в случае невозмож-
ности построения грамматического анализатора. В тексте сооб-
щения, предваряемом заголовком "ошибка:", содержится указа-
ние причины ошибки и номер просматриваемой в момент ее появ-
ления строки спецификационного файла. Перечислим основные
типы фиксируемых yacc ошибок:
неверно заданные флаги командной строки;
невозможность открытия входного или временных файлов;
отсутствие файла /usr/lib/yaccpar с текстом процедуры
yyparse;
неверная структура спецификационного файла;
ошибки в задании директив;
синтаксические ошибки в описании грамматических правил,
незавершенность комментариев, строк символов и дейст-
вий;
- 32 -
некорректное использование псевдопеременных;
неопределенные нетерминальные символы;
нарушение количественных ограничений (по числу терми-
нальных или нетерминальных символов, грамматических
правил, состояний и проч.).
- 33 -
Приложение 1
Ниже приведен полный входной файл для yacc, реализующий
небольшой настольный калькулятор; калькулятор имеет 26
регистров, помеченных буквами от a до z и разрешает исполь-
зовать арифметические выражения, содержащие операции +, -,
*, /, % (остаток от деления), & (побитовое и), | (побитовое
или) и присваивание. Как и в Си, целые числа, начинающиеся с
0, считаются восьмеричными, все остальные - десятичными.
В примере демонстрируются способы использования приори-
тетов для разрешения конфликтов, а также простые операции по
восстановлению из состояния ошибки. Калькулятор работает в
интерактивном режиме с построчным формированием выхода.
%token DIGIT LETTER /* имена лексем */
%left '|' /* задание приоритетов */
%left '&' /* операций */
%left '+' '-'
%left '*' '/' '%'
%left UMINUS /* установка приоритета
операции унарный минус */
%{ /* oписания, используемые */
int base, regs[26]; /* в действиях */
%}
%% /* начало секции правил */
list:
| list stat '\n'
| list stat error '\n' {yyerrok; }
stat:
expr {printf("%d\n",$1);}
| LETTER '=' expr {regs[$1]=$3; }
expr:
'(' expr ')' { $$=$2; }
| expr '+' expr { $$=$1+$3; }
| expr '-' expr { $$=$1-$3; }
| expr '*' expr { $$=$1*$3; }
| expr '/' expr { $$=$1/$3; }
| expr '%' expr { $$=$1%$3; }
| expr '&' expr { $$=$1&$3; }
| expr '|' expr { $$=$1|$3; }
| '-' expr %prec UMINUS { $$= -$2; }
| LETTER { $$=regs[$1]; }
| number;
number:
DIGIT { $$=$1; base=10;
if($1==0) base=8; }
- 34 -
| number DIGIT {$$=base*$1+$2; }
%% /* начало секции программ */
/*
* Программа лексического анализа
* для строчных латинских букв
* возвращает LETTER,
* значение yylval от 0 до 25;
* для цифр - DIGIT,
* значение yylval от 0 до 9;
* остальные символы возвращаются
* непосредственно
*/
yylex()
{
int c;
while( (c=getchar()) == ' ' );
if( c>='a' && c<='z' ) {
yylval = c - 'a';
return(LETTER);
}
if( c>='0' && c<='9' ) {
yylval = c - '0';
return(DIGIT);
}
return(c);
}
- 35 -
Приложение 2
Анализ и преобразование в матричную форму входных дан-
ных для задачи линейного программирования.
Входная информация из обычной алгебраической формы:
c1X1+c2X2+...+cnXn -> min(max)
a11x1+a12X2+...+a1nXn=b1
am1X1+am2X2+...+amnXn=bm
преобразуется в матричную:
C: c1 c2 ... cn
A: a11 a12 ... a1n
...
am1 am2 ... amn
B: b1 b2 ... bm
Одновременно изменяются знаки коэффициентов при неизвестных
в ограничениях с отрицательным свободным членом, а также
знаки коэффициентов линейного функционала в случае его мак-
симизации. С иллюстративной целью допускаются некоторые
варианты синтаксической записи. Предусмотрена возможность
повторного задания ошибочных строк.
%token число Xi оптим
%%
злп:функционал '\n' система_ограничений
{final();}
| система_ограничений функционал '\n'
{ final();}
функционал: линейная_функция {stf();}
/* По умолчанию - минимизация */
| оптим '(' линейная_функция ')'
{if($1) conv(); stf();}
/* В случае максимизации выполнить conv() */
| линейная_функция '-''>' оптим
{if($4) conv();stf();}
линейная_функция: элем1
| линейная_функция элем ;
элем: знак число Xi {stc($1*$2,$3); }
| знак Xi '*' число { stc($1*$4,$2);}
| знак Xi { stc($1,$2);}
/* Формы записи коэффициентов */
элем1: элем
| число Xi { stc($1,$2);}
| Xi '*' число { stc($3,$1);}
- 36 -
| Xi { stc(1,$1); }
знак: '+' {$$=1; }
| '-' {$$= -1;}
система_ограничений: ограничение '\n'
| система_ограничений ограничение '\n'
| система_ограничений error '\n'
{aclear();yyerrok;
printf("повторите последнюю строку\n");}
/* В случае ошибки: стирание инф. о строке,
восстановление и выдача подсказки */
ограничение: линейная_функция '=' число
{ stcb($3);}
| линейная_функция '=' знак число
{ if($3<0) conv(); stcb($4);}
/* Если bi<0, выполнить conv() */
%%
#include "stdio.h"
#define MAXM 100 /* предельное число */
#define MAXN 100 /* ограничений и перем.*/
int c[MAXN],b[MAXM],a[MAXM+1][MAXN],
/* Лексический анализатор возвращает:
* для целых чисел - число,
* yylval равно знач. числа;
* для идент.вида xi, i=1,2,...XI*
* yylval равно его порядк. номеру;
* для max/min - оптим,
* yylval равно соответственно 1 или 0
*/
yylex() {
char c,i;
while((c=getc(stdin))==' ');
switch(c) {
case'0':
case'1':
case'2':
case'3':
case'4':
case'5':
case'6':
case'7':
case'8':
case'9': yylval=c-'0';
while((c=getc(stdin))<='9'&&c>='0')
yylval=yylval*10+c-'0';
ungetc(c,stdin); return(число);
- 37 -
case'm': if((c=getc(stdin))=='i') yylval=0;
else if(c=='a') yylval=1;
else return('m');
while((c=getc(stdin))<='z'&&c>='a');
ungetc(c,stdin); return(оптим);
case'X':
case'x': if((c=getc(stdin))<'0' || c>'9')
return('x');
yylval=0;
while(c<='9'&&c>='0')
{yylval=yylval*10+c-'0';c=getc(stdin);}
ungetc(c,stdin);
for(i=0;i<nx;i++)
if(x[i]==yylval){yylval=i;return(Xi);}
x[nx]=yylval; yylval=nx++;return(Xi);
}
return(c);
}
/* Печать условия задачи в матричной форме */
final() {
char i,j;
printf("c:\n");
for(i=0;i<nx;i++) printf("%8d",c[i]);
printf("\na:\n");
for(i=0;i<neqs;i++) {
for(j=0;j<nx;j++) printf("%8d",a[i][j]);
printf("\n"); }
printf("b:\n");
for(i=0;i<neqs;i++) printf("%8d",b[i]);
}
/* Изменение знаков коэффициентов */
conv() {
char i;
for(i=0;i<nx;i++) a[neqs][i]*=(-1);
}
/* Запоминание коэффициентов функционала */
stf() {
char i;
for(i=0;i<nx;i++)
{ c[i]=a[neqs][i]; a[neqs][i]=0; }
}
/* Запоминание очередного коэффициента */
stc(nmb,adr) {
a[neqs][adr]=nmb; }
/* Запоминание свободного члена */
stcb(nmb) {
b[neqs++]=nmb; }
- 38 -
/* Стирание ошибочной строки*/
aclear(){
char i;
for(i=0;i<nx;i++)
a[neqs][i]=0;
}
- 39 -
Приложение 3
Формальное описание структуры спецификационного файла.
файл_спецификаций:
секция_деклараций '%''%'
'\n' секция_правил '%''%'
'\n' секция_программ
| секция_деклараций '%''%'
'\n' секция_правил ;
секция_деклараций:
| секция_деклараций дир_или_описание
'\n' ;
дир_или_описание:
'%''{''\n'ВНЕШНИЕ_ОПИСАНИЯ
'\n''%''}'
| '%''s''t''a''r''t' ИДЕНТИФИКАТОР
| '%''t''o''k''e''n'список_им_лексем
| ассоциативность список_лексем ;
ассоциативность:
'%''l''e''f''t'
| '%'''r''i''g''h''t'
| '%''n''o''n''a''s''s''o''c' ;
список_им_лексем:
| декл_имени_лексемы
| список_им_лексем
декл_имени_лексемы ;
список_лексем:
декл_лексемы
| список_лексем декл_лексемы ;
декл_имени_лексемы:
ИДЕНТИФИКАТОР
| ИДЕНТИФИКАТОР ЦЕЛОЕ_БЕЗ_ЗНАКА;
декл_лексемы:
декл_лексемы
| декл_литерала;
декл_литерала:
ЛИТЕРАЛ
| ЛИТЕРАЛ ЦЕЛОЕ_БЕЗ_ЗНАКА;
секция_правил:
набор_правил
| '%''{''\n'СИ_ОПЕРАТОРЫ'\n''%''}'
'\n' набор_правил '\n' ;
набор_правил:
правило
| набор_правил ';' правило ;
правило:
левая_часть ':' альтернатива
| правило '|' альтернатива ;
левая_часть: ИДЕНТИФИКАТОР ;
альтернатива:
- 40 -
правая_часть
| правая_часть изм_приор
| правая_часть изм_приор действие
| правая_часть действие ;
правая_часть:
| правая_часть лит_или_идент
| правая_часть действие лит_или_идент;
изм_приор:
секция_программ:
ПРОГРАММНЫЕ_КОМПОНЕНТЫ ;
При описании структуры спецификационного файла не рас-
шифровывались некоторые исходные конструкции, совпадающие с
аналогичными конструкциями Си: идентификатор, литерал, целое
без знака. Не описаны также и более сложные конструкции,
являющиеся фрагментами Си-программ, переносимыми в текст
анализатора (внешние описания, Си-операторы). Под расширен-
ными Си-операторами понимаются операторы с возможным исполь-
зованием псевдопеременных. ПРОГРАММНЫЕ_КОМПОНЕНТЫ включают
операторы препроцессора, описания внешних переменных и функ-
ций (возможный состав их приводится в разделе 4.3).
- 41 -
СОДЕРЖАНИЕ
. Аннотация ......................................... 2
1. Принципы работы yacc .............................. 3
2. Входные и выходные файлы, структура грамматического
анализатора ....................................... 4
3. Процедура построения грамматического анализатора .. 5
4. Задание входной информации yacc ................... 6
4.1. Структура спецификационного файла ............... 6
4.2. Секция правил ................................... 7
4.3. Секция деклараций ............................... 12
5. Декларация имен лексем ............................ 13
6. Декларация приоритетов и ассоциативности лексем ... 13
7. Декларация имени начального символа ............... 15
7.1. Секция программ ................................. 15
7.2. Действия с использованием псевдопеременных ...... 17
8. Конфликты грамматического разбора ................. 20
9. Структура информационного входного файла
y.output .......................................... 27
10. Обработка ошибок при грамматическом разборе ....... 29
11. Диагностика ошибок ................................ 32
Приложение 1 ...................................... 34
Приложение 2 ...................................... 36
Приложение 3 ...................................... 40
- 42 -
Популярность: 7, Last-modified: Mon, 29 Jun 1998 14:15:22 GmT