yaccposix - Online na nuvem

PROGRAMA:

NOME

yacc - mais um compilador compilador (DESENVOLVIMENTO)

SINOPSE

yacc [−dltv] [-b prefixo_arquivo] [-p prefixo_sim] gramática

DESCRIÇÃO

A yacc utilitário deve ler uma descrição de uma gramática livre de contexto em gramática e escrever C
código-fonte, em conformidade com o padrão ISO C, para um arquivo de código e, opcionalmente, cabeçalho
informações em um arquivo de cabeçalho, no diretório atual. O código-fonte gerado deve
não dependem de qualquer comportamento indefinido, não especificado ou definido pela implementação, exceto em
casos em que é copiado diretamente da gramática fornecida, ou em casos que são
documentado pela implementação. O código C deve definir uma função e rotinas relacionadas
e macros para um autômato que executa um algoritmo de análise que atende aos requisitos em
Algoritmos.

A forma e o significado da gramática são descritos na seção DESCRIÇÃO ESTENDIDA.

O código-fonte C e o arquivo de cabeçalho devem ser produzidos em uma forma adequada como entrada para o C
compilador (ver c99).

OPÇÕES

A yacc utilitário deve estar em conformidade com o volume de Definições de Base de POSIX.1‐2008, Seção
12.2, Utilidade Sintaxe orientações, exceto para a Diretriz 9.

As seguintes opções devem ser suportadas:

-b prefixo_arquivo
Use prefixo_arquivo em vez de y como o prefixo para todos os nomes de arquivos de saída. O código
lima y.tab.c, o arquivo de cabeçalho y.tab.h (criado quando -d é especificado), e o
arquivo de descrição y.saída (criado quando −v é especificado), deve ser alterado para
prefixo_arquivo.tab.c, prefixo_arquivo.tab.h e prefixo_arquivo.saída, Respectivamente.

-d Grave o arquivo de cabeçalho; por padrão, apenas o arquivo de código é gravado. O #define
declarações associam os códigos de token atribuídos por yacc com o usuário declarado
nomes de tokens. Isso permite outros arquivos de origem que não y.tab.c para acessar o token
códigos.

−eu Produza um arquivo de código que não contenha nenhum #linha constrói. Se esta opção
não está presente, não é especificado se o arquivo de código ou arquivo de cabeçalho contém
#linha diretivas. Isso só deve ser usado após a gramática e o associado
as ações são totalmente depuradas.

-p prefixo_sim
Use prefixo_sim em vez de yy como o prefixo para todos os nomes externos produzidos por
yacc. Os nomes afetados devem incluir as funções yyparse() yylex(), e
erro(), e as variáveis Yylval, yychar e yydebug. (No restante de
nesta seção, os seis símbolos citados são referenciados usando seus nomes padrão
apenas como uma notação de conveniência.) Os nomes locais também podem ser afetados pelo -p
opção; No entanto, o -p opção não afetará #define símbolos gerados por
yacc.

-t Modifique as diretivas de compilação condicional para permitir a compilação de depuração
código no arquivo de código. As instruções de depuração em tempo de execução devem sempre estar contidas em
o arquivo de código, mas por padrão as diretivas de compilação condicional evitam que
compilação.

−v Escreva um arquivo contendo uma descrição do analisador e um relatório de conflitos
gerado por ambigüidades na gramática.

OPERANDOS

O seguinte operando é necessário:

gramática Um nome de caminho de um arquivo contendo instruções, doravante denominado gramática, Por
em que um analisador deve ser criado. O formato da gramática é descrito no
Seção DESCRIÇÃO ESTENDIDA.

STDIN

Não usado.

INPUT ARQUIVOS

O arquivo gramática deve ser um arquivo de texto formatado conforme especificado na DESCRIÇÃO ESTENDIDA
seção.

MEIO AMBIENTE VARIÁVEIS

As seguintes variáveis ​​de ambiente devem afetar a execução de yacc:

GRANDE Forneça um valor padrão para as variáveis ​​de internacionalização que não estão definidas ou
nulo. (Veja o volume de Definições de Base de POSIX.1‐2008, Seção 8.2,
Internacionalização Variáveis pela precedência de internacionalização
variáveis ​​usadas para determinar os valores das categorias de local.)

LC_ALL Se definido como um valor de string não vazio, substitui os valores de todos os outros
variáveis ​​de internacionalização.

LC_CTYPE Determine o local para a interpretação de sequências de bytes de dados de texto
como caracteres (por exemplo, caracteres de byte único em oposição a caracteres de bytes múltiplos em
argumentos e arquivos de entrada).

LC_MESSAGES
Determine a localidade que deve ser usada para afetar o formato e o conteúdo do
mensagens de diagnóstico gravadas no erro padrão.

NLSPAT Determine a localização dos catálogos de mensagens para o processamento de LC_MESSAGES.

A GRANDE e LC_ * variáveis ​​afetam a execução do yacc utilidade conforme declarado. O principal()
função definida em Yacc Biblioteca deve chamar:

setlocale (LC_ALL, "")

e, portanto, o programa gerado por yacc também serão afetados pelo conteúdo destes
variáveis ​​em tempo de execução.

ASSÍNCRONO EVENTOS

Padrão.

STDOUT

Não usado.

STDERR

Se mudar / reduzir ou reduzir / reduzir conflitos forem detectados em gramática, yacc deve escrever um
relatório desses conflitos para o erro padrão em um formato não especificado.

O erro padrão também deve ser usado para mensagens de diagnóstico.

SAÍDA ARQUIVOS

O arquivo de código, o arquivo de cabeçalho e o arquivo de descrição devem ser arquivos de texto. Todos são
descrito nas seções a seguir.

Code Envie o
Este arquivo deve conter o código-fonte C para o yyparse() função. Deve conter
código para as várias ações semânticas com substituição de macro realizada nelas como
descrito na seção DESCRIÇÃO ESTENDIDA. Ele também deve conter uma cópia do #define
declarações no arquivo de cabeçalho. Se um %União declaração é usada, a declaração para
YYSTYPE também deve ser incluído neste arquivo.

cabeçalho Envie o
O arquivo de cabeçalho deve conter #define declarações que associam os números do token com o
nomes de tokens. Isso permite que arquivos de origem diferentes do arquivo de código acessem os códigos de token.
Se um %União declaração é usada, a declaração para YYSTYPE e um externo YYSTYPE Yylval
declaração também deve ser incluída neste arquivo.

Descrição Envie o
O arquivo de descrição deve ser um arquivo de texto contendo uma descrição da máquina de estado
correspondente ao analisador, usando um formato não especificado. Limites para tabelas internas (ver
Limites) também devem ser relatados, de uma forma definida pela implementação. (Algumas implementações
podem usar técnicas de alocação dinâmica e não têm valores-limite específicos para relatar.)

ESTENDIDO DESCRIÇÃO

A yacc comando aceita um idioma que é usado para definir uma gramática para um idioma de destino
para ser analisado pelas tabelas e códigos gerados por yacc. O idioma aceito por yacc como um
gramática para o idioma de destino é descrita abaixo usando o yacc idioma de entrada em si.

A entrada gramática inclui regras que descrevem a estrutura de entrada do idioma de destino e
código a ser invocado quando essas regras são reconhecidas para fornecer a semântica associada
açao. O código a ser executado deve aparecer como corpos de texto que se destinam a ser C-
código de idioma. Esses corpos de texto não devem conter trigrafos em linguagem C. A linguagem C
inclusões são presumidas para formar uma função correta quando processadas por yacc em sua saída
arquivos. O código incluído desta forma deve ser executado durante o reconhecimento do
idioma de destino.

Dada uma gramática, o yacc utilitário gera os arquivos descritos em OUTPUT FILES
seção. O arquivo de código pode ser compilado e vinculado usando c99. Se a declaração e
seções de programas do arquivo de gramática não incluíam definições de principal() yylex(), e
erro(), a saída compilada requer vinculação com versões fornecidas externamente daqueles
funções. Versões padrão de principal() e erro() são fornecidos no yacc biblioteca e
pode ser conectado usando o −eu y operando para c99. O yacc interfaces de biblioteca não precisam
suporte a interfaces com outras que não as padrão yy prefixo do símbolo. O aplicativo fornece
a função do analisador léxico, yylex(); a lex utilitário é projetado especificamente para
gerar tal rotina.

Entrada Língua
A aplicação deve garantir que cada arquivo de especificação consiste em três seções em
ordem: declarações, gramática regras e programas, separado por duplo
personagens ("%%") As seções de declarações e programas podem estar vazias. Se o último for
vazio, o anterior "%%" a marca que o separa da seção de regras pode ser omitida.

A entrada é um texto de formato livre seguindo a estrutura da gramática definida abaixo.

Lexical Estrutura of que o Gramática
O , , e personagem deve ser ignorado, exceto que o
aplicação deve garantir que eles não apareçam em nomes ou caracteres reservados
símbolos. Os comentários devem ser colocados em "/ * ... * / ", e pode aparecer onde quer que haja um nome
válido.

Os nomes são de comprimento arbitrário, compostos por letras, pontos ('.'), sublinhados ('_'), E
dígitos não iniciais. Letras maiúsculas e minúsculas são distintas. Aplicativos em conformidade
não deve usar nomes que começam com yy or YY uma vez que o yacc analisador usa esses nomes. Muitos
os nomes aparecem na saída final de yacc, e, portanto, devem ser escolhidos para se conformarem
com quaisquer regras adicionais criadas pelo compilador C a serem usadas. Em particular, eles aparecem
in #define afirmações.

Um literal deve consistir em um único caractere entre aspas simples. Tudo de
as sequências de escape suportadas para constantes de caracteres pelo padrão ISO C devem ser
suportado pela yacc.

A relação com o analisador léxico é discutida em detalhes abaixo.

O aplicativo deve garantir que o caractere NUL não seja usado nas regras gramaticais ou
literais.

Declarações Seção
A seção de declarações é usada para definir os símbolos usados ​​para definir o idioma de destino
e sua relação um com o outro. Em particular, muitas das informações adicionais
necessário para resolver ambigüidades na gramática livre de contexto para o idioma de destino é
fornecido aqui.

Geralmente yacc atribui a relação entre os nomes simbólicos que gera e seus
valor numérico subjacente. A seção de declarações torna possível controlar o
atribuição desses valores.

Também é possível manter as informações semânticas associadas aos tokens atualmente em
a pilha de análise em uma linguagem C definida pelo usuário união, se os membros do sindicato são
associado aos vários nomes da gramática. A seção de declarações prevê
isso também.

O primeiro grupo de declaradores abaixo recebe uma lista de nomes como argumentos. Essa lista pode
opcionalmente ser precedido pelo nome de um membro do sindicato C (chamado de etiqueta abaixo) aparecendo
dentro '<' e '>'. (Como uma exceção às convenções tipográficas do resto deste
volume de POSIX.1‐2008, neste casoetiqueta> não representa uma metavariavel, mas o
caracteres de colchetes angulares literais em torno de um símbolo.) O uso de etiqueta especifica que o
tokens nomeados nesta linha devem ser do mesmo tipo C que o membro do sindicato referenciado por
etiqueta. Isso é discutido com mais detalhes abaixo.

Para listas usadas para definir tokens, a primeira aparição de um determinado token pode ser seguida por
um número inteiro positivo (como uma sequência de dígitos decimais). Se isso for feito, o valor subjacente
atribuído a ele para fins lexicais será considerado esse número.

O seguinte declara nome para ser um token:

%símbolo [<etiqueta>] nome [número] [nome [número]]...

If etiqueta estiver presente, o tipo C para todos os tokens nesta linha deve ser declarado como o tipo
referenciado por etiqueta. Se um número inteiro positivo, número, segue um nome, esse valor deve ser
atribuído ao token.

O seguinte declara nome para ser um token e atribui precedência a ele:

%deixou [<etiqueta>] nome [número] [nome [número]]...
%direito [<etiqueta>] nome [número] [nome [número]]...

Uma ou mais linhas, cada uma começando com um desses símbolos, podem aparecer nesta seção.
Todos os tokens na mesma linha têm o mesmo nível de precedência e associatividade; as linhas
estão em ordem crescente de precedência ou força de ligação. %deixou denota que o
operadores nessa linha são associativos à esquerda e %direito da mesma forma denota certo
operadores associativos. Se etiqueta está presente, deve declarar um tipo C para nomeconforme descrito
para %símbolo.

O seguinte declara nome para ser um token e indica que não pode ser usado
associativamente:

% nonassoc [<etiqueta>] nome [número] [nome [número]]...

Se o analisador encontrar o uso associativo desse token, ele relatará um erro. Se etiqueta is
presente, deve declarar um tipo C para nomes conforme descrito para %símbolo.

O seguinte declara que o membro do sindicato nomes não são terminais e, portanto, são obrigatórios
ter um etiqueta campo em seu início:

%tipo <etiqueta> nome...

Como ele lida apenas com não terminais, atribuir um número de token ou usar um literal é
também proibido. Se esta construção estiver presente, yacc deve realizar verificação de tipo; se este
construção não está presente, a pilha de análise deve conter apenas o int tipo.

Cada nome usado em gramática não definido por um %símbolo, %deixou, %direitoou % nonassoc
a declaração é considerada representar um símbolo não terminal. O yacc utilidade deve relatar
um erro para qualquer símbolo não terminal que não apareça no lado esquerdo de pelo menos um
regra gramatical.

Uma vez que o tipo, precedência ou número de token de um nome é especificado, ele não deve ser
mudado. Se a primeira declaração de um token não atribuir um número de token, yacc deve
atribuir um número de token. Uma vez que esta atribuição é feita, o número do token não deve ser alterado
por atribuição explícita.

Os declaradores a seguir não seguem o padrão anterior.

O seguinte declara o não terminal nome para ser o começo símbolo, que representa o
estrutura maior e mais geral descrita pelas regras gramaticais:

%começar nome

Por padrão, é o lado esquerdo da primeira regra gramatical; este padrão pode ser
substituído por esta declaração.

O seguinte declara o yacc pilha de valores para ser uma união de vários tipos de valores
desejado.

%União { corpo of união (in C)}

O corpo da união não deve conter tokens de pré-processamento de chaves não balanceadas.

Por padrão, os valores retornados pelas ações (ver abaixo) e o analisador léxico devem ser
do tipo int. O yacc utilitário mantém o controle dos tipos, e deve inserir os correspondentes
nomes de membros de união para executar verificação de tipo estrita do analisador resultante.

Alternativamente, dado que pelo menos umetiqueta> construção é usada, a união pode ser declarada
em um arquivo de cabeçalho (que deve ser incluído na seção de declarações usando um #include
construir dentro %{ e %}) e um typedef usado para definir o símbolo YYSTYPE para representar
esta união. O efeito de %União é fornecer a declaração de YYSTYPE diretamente de
que o yacc entrada.

As declarações e definições da linguagem C podem aparecer na seção de declarações, incluída
pelas seguintes marcas:

%{ ... %}

Essas declarações devem ser copiadas para o arquivo de código e ter escopo global dentro dele,
que eles podem ser usados ​​nas regras e seções do programa. As declarações não devem conter
"%}" fora de um comentário, literal de string ou constante de vários caracteres.

O aplicativo deve garantir que a seção de declarações seja encerrada pelo token %%.

Gramática Regras in yacc
A seção de regras define a gramática livre de contexto a ser aceita pela função yacc
gera e associa a essas regras ações da linguagem C e precedência adicional
em formação. A gramática é descrita abaixo e uma definição formal segue.

A seção de regras é composta por uma ou mais regras gramaticais. Uma regra gramatical tem a forma:

A : BODY ;

O símbolo A representa um nome não terminal, e BODY representa uma sequência de zero ou
mais nomes, literals, e semântico açaos que podem ser seguidos por opcionais
precedência governars. Apenas os nomes e literais participam da formação do
gramática; as ações semânticas e as regras de precedência são usadas de outras maneiras. O e
a são yacc pontuação. Se houver várias regras gramaticais sucessivas com
o mesmo lado esquerdo, o ('|') pode ser usado para evitar a reescrita do
lado esquerdo; neste caso o aparece apenas após a última regra. O corpo
parte pode estar vazia (ou vazia de nomes e literais) para indicar que o não terminal
símbolo corresponde à string vazia.

A yacc utilitário atribui um número exclusivo para cada regra. Regras usando a barra vertical
notação são regras distintas. O número atribuído à regra aparece na descrição
arquivo.

Os elementos que compõem um CORPO são:

nome, literal
Elas formam as regras da gramática: nome é um token ou um não terminal;
literal representa a si mesmo (menos as aspas exigidas lexicamente).

semântico açao
Com cada regra gramatical, o usuário pode associar ações a serem realizadas cada vez
a regra é reconhecida no processo de entrada. (Observe que a palavra `` ação '' pode
também consulte as ações do analisador - deslocar, reduzir e assim por diante.)

Essas ações podem retornar valores e podem obter os valores retornados por anteriores
ações. Esses valores são mantidos em objetos do tipo YYSTYPE (ver %União). O
o valor do resultado da ação deve ser mantido na pilha de análise com a mão esquerda
lado da regra, para ser acessado por outras reduções como parte de sua mão direita
lateral. Usando oetiqueta> informações fornecidas na seção de declarações, o
código gerado por yacc pode ser estritamente verificado por tipo e conter
em formação. Além disso, o analisador léxico pode fornecer os mesmos tipos de
valores para tokens, se desejado.

Uma ação é uma instrução C arbitrária e, como tal, pode fazer entrada ou saída, chamar
subprogramas e alterar variáveis ​​externas. Uma ação é uma ou mais declarações C
entre colchetes '{' e '}'. As declarações não devem conter
tokens de pré-processamento de chaves não balanceadas.

Certas pseudo-variáveis ​​podem ser usadas na ação. Estas são macros para acesso
a estruturas de dados conhecidas internamente por yacc.

$$ O valor da ação pode ser definido atribuindo-o a $$. Se tipo
a verificação está habilitada e o tipo de valor a ser atribuído não pode ser
determinado, uma mensagem de diagnóstico pode ser gerada.

$número Isso se refere ao valor retornado pelo componente especificado pelo
token número no lado direito de uma regra, lendo da esquerda para a direita;
número pode ser zero ou negativo. Se número é zero ou negativo,
refere-se aos dados associados ao nome na pilha do analisador
precedendo o símbolo mais à esquerda da regra atual. (Aquilo é, "$ 0"
refere-se ao nome imediatamente anterior ao nome mais à esquerda no
regra atual a ser encontrada na pilha do analisador e "$ -1" refere-se ao
símbolo para Está esquerda.) Se número refere-se a um elemento além do atual
ponto na regra, ou além da parte inferior da pilha, o resultado é
Indefinido. Se a verificação de tipo estiver habilitada e o tipo do valor a ser
atribuído não pode ser determinado, uma mensagem de diagnóstico pode ser gerada.

$<etiqueta>número
Estes correspondem exatamente aos símbolos correspondentes sem o etiqueta
inclusão, mas permite a verificação estrita de tipo (e impede
conversões de tipo). O efeito é que a macro é expandida para usar etiqueta
para selecionar um elemento da união YYSTYPE (usando nomedosdados.tag).
Isso é particularmente útil se número não é positivo.

$<etiqueta> $ Isto impõe na referência o tipo de membro do sindicato referenciado
by etiqueta. Esta construção é aplicável quando uma referência a uma esquerda
valor de contexto ocorre na gramática e fornece yacc com um meio
para selecionar um tipo.

As ações podem ocorrer em qualquer lugar em uma regra (não apenas no final); uma ação pode acessar
valores retornados por ações à sua esquerda e, por sua vez, o valor que retorna pode ser
acessado por ações à sua direita. Uma ação que aparece no meio de uma regra
deve ser equivalente a substituir a ação por um novo símbolo não terminal e
adicionar uma regra vazia com aquele símbolo não terminal no lado esquerdo. O
ação semântica associada à nova regra deve ser equivalente ao original
açao. O uso de ações dentro das regras pode introduzir conflitos que não
caso contrário, existe.

Por padrão, o valor de uma regra deve ser o valor do primeiro elemento nela.
Se o primeiro elemento não tiver um tipo (particularmente no caso de um
literal) e a verificação de tipo é ativada por %tipo, uma mensagem de erro deve resultar.

precedência
A palavra-chave % prec pode ser usado para alterar o nível de precedência associado a um
regra gramatical particular. Exemplos disso são os casos em que um unário e um binário
operador têm a mesma representação simbólica, mas precisam receber diferentes
precedências, ou onde o tratamento de uma construção if-else ambígua é
necessário. O símbolo reservado % prec pode aparecer imediatamente após o corpo de
a regra gramatical e pode ser seguido por um nome de token ou um literal. Deve
fazer com que a precedência da regra gramatical se torne a do token seguinte
nome ou literal. A ação para a regra como um todo pode seguir % prec.

Se uma seção do programa segue, o aplicativo deve garantir que as regras gramaticais são
terminado por %%.

Programas Seção
A programas seção pode incluir a definição do analisador léxico yylex(), e qualquer
Outras funções; por exemplo, aqueles usados ​​nas ações especificadas nas regras gramaticais. Isto
não é especificado se a seção de programas precede ou segue as ações semânticas em
o arquivo de saída; portanto, se o aplicativo contém quaisquer definições de macro e
declarações destinadas a aplicar ao código nas ações semânticas, deve colocá-los
dentro "% { ... %} " na seção de declarações.

Entrada Gramática
A seguinte entrada para yacc produz um analisador para a entrada para yacc. Esta sintaxe formal
tem precedência sobre a descrição da sintaxe de texto anterior.

A estrutura lexical é definida com menos precisão; Lexical Estrutura of que o Gramática define
a maioria dos termos. A correspondência entre os termos anteriores e os tokens abaixo é como
Segue.

IDENTIFICADOR Isso corresponde ao conceito de nome, fornecido anteriormente. Também inclui
literais conforme definido anteriormente.

C_IDENTIFICADOR
Este é um nome e, adicionalmente, é conhecido por ser seguido por um . UMA
literal não pode gerar este token.

NÚMERO Uma sequência de dígitos (um inteiro decimal não negativo).

TIPO, ESQUERDA, MARCA, LCURL, RCURL
Estes correspondem diretamente a %tipo, %deixou, %%, %{ e %}.

{ ... } Isso indica o código-fonte da linguagem C, com a possível inclusão de '$'
macros conforme discutido anteriormente.

/* Gramática para que o entrada para sim. */
/* Basico entradas. */
/* A seguinte e guarante que os mesmos estão reconhecido by que o lexical analisador. */

% token IDENTIFIER / * Inclui identificadores e literais * /
% token C_IDENTIFIER / * identificador (mas não literal)
seguido por um:. * /
% token NUMBER / * [0-9] [0-9] * * /

/ * Palavras reservadas:% type => TYPE% left => LEFT, e assim por diante * /

% token ESQUERDA DIREITA NONASSOC TOKEN PREC TYPE START UNION

% token MARK / * A marca %%. * /
% token LCURL / * A marca% {. * /
% token RCURL / * A marca%}. * /

/ * Literais de caracteres de 8 bits representam eles próprios; * /
/ * tokens devem ser definidos para caracteres multibyte. * /

% start spec

%%

especificação: cauda de regras defs MARK
;
cauda: MARK
{
/ * Nesta ação, configure o resto do arquivo. * /
}
| /* Vazio; a segunda MARCA é opcional. * /
;
defs: / * Vazio. * /
| defs def
;
def: INICIAR IDENTIFICADOR
| UNIÃO
{
/ * Copia a definição da união para a saída. * /
}
| LCURL
{
/ * Copia o código C para o arquivo de saída. * /
}
RCURL
| lista de tags rword
;
rword: TOKEN
| DEIXOU
| DIREITO
| NÃO ASSOC
| MODELO
;
tag: / * Vazio: ID de tag de união opcional. * /
| '<' IDENTIFICADOR '>'
;
nlist: nmno
| nlista nmno
;
nmno: IDENTIFIER / * Nota: literal inválido com% type. * /
| NÚMERO DE IDENTIFICADOR / * Nota: inválido com% type. * /
;

/ * Seção de regra * /

regras: C_IDENTIFIER rbody prec
| regra de regras
;
regra: C_IDENTIFIER rbody prec
| '|' rbody prec
;
rbody: / ​​* vazio * /
| rbody IDENTIFICADOR
| rbody agir
;
agir : '{'
{
/ * Copiar ação, traduzir $$ e assim por diante. * /
}
'}'
;
prec: / * vazio * /
| PREC IDENTIFICADOR
| Ato PREC IDENTIFIER
| prec ';'
;

Conflitos
O analisador produzido para uma gramática de entrada pode conter estados em que ocorrem conflitos. O
conflitos ocorrem porque a gramática não é LALR(1). Uma gramática ambígua sempre contém
pelo menos um LALR(1) conflito. O yacc utilitário deve resolver todos os conflitos, usando qualquer um
regras padrão ou regras de precedência especificadas pelo usuário.

Os conflitos podem mudar / reduzir conflitos ou reduzir / reduzir conflitos. Uma mudança / redução
conflito é onde, para um determinado estado e símbolo de antevisão, tanto uma ação de mudança quanto uma
reduzir a ação são possíveis. Um conflito de reduzir / reduzir é onde, para um determinado estado e
símbolo de antevisão, reduções por duas regras diferentes são possíveis.

As regras abaixo descrevem como especificar quais ações tomar quando ocorrer um conflito. Não
todos os conflitos de mudança / redução podem ser resolvidos com sucesso desta forma porque o conflito pode
ser devido a algo diferente de ambigüidade, então o uso descuidado dessas instalações pode causar
a linguagem aceita pelo analisador como sendo muito diferente daquela pretendida. O
arquivo de descrição deve conter informações suficientes para entender a causa do
conflito. Onde a ambigüidade é o motivo pelo qual as regras padrão ou explícitas devem ser
adequado para produzir um analisador funcional.

As precedências e associatividades declaradas (ver Declarações Seção) estão acostumados a
resolver conflitos de análise da seguinte maneira:

1. Uma precedência e associatividade estão associadas a cada regra gramatical; é o
precedência e associatividade do último token ou literal no corpo da regra. Se
que o % prec palavra-chave for usada, ela substitui esse padrão. Algumas regras gramaticais podem não
têm precedência e associatividade.

2. Se houver um conflito de mudança / redução, e a regra gramatical e o símbolo de entrada
têm precedência e associatividade associadas a eles, então o conflito é resolvido
em favor da ação (mudar ou reduzir) associada à precedência mais alta. Se o
as precedências são as mesmas, então a associatividade é usada; associativo à esquerda implica
reduzir, associativo à direita implica mudança e não associativo implica um erro no
string sendo analisada.

3. Quando há um conflito de mudança / redução que não pode ser resolvido pela regra 2, a mudança é
feito. Os conflitos resolvidos desta forma são contados na saída de diagnóstico descrita em
erro Manipulação.

4. Quando há um conflito de redução / redução, uma redução é feita pela regra gramatical que
ocorre mais cedo na sequência de entrada. Os conflitos resolvidos desta forma são contados no
saída de diagnóstico descrita em erro Manipulação.

Conflitos resolvidos por precedência ou associatividade não devem ser contados na mudança / redução
e reduzir / reduzir os conflitos relatados por yacc no erro padrão ou no
arquivo de descrição.

erro Manipulação
O token erro deve ser reservado para tratamento de erros. O nome erro pode ser usado em
regras de gramática. Indica locais onde o analisador pode se recuperar de um erro de sintaxe. O
valor padrão de erro deve ser 256. Seu valor pode ser alterado usando um %símbolo declaração.
O analisador léxico não deve retornar o valor de erro.

O analisador deve detectar um erro de sintaxe quando está em um estado onde a ação está associada
com o símbolo de lookahead é erro. Uma ação semântica pode fazer com que o analisador inicie
tratamento de erros executando a macro YYERROR. Quando YYERROR é executado, a semântica
a ação devolve o controle ao analisador. YYERROR não pode ser usado fora da semântica
ações.

Quando o analisador detecta um erro de sintaxe, ele normalmente chama erro() com o personagem
corda "sintaxe erro" como seu argumento. A chamada não deve ser feita se o analisador ainda estiver
recuperando de um erro anterior quando o erro é detectado. O analisador é considerado
estar se recuperando de um erro anterior até que o analisador tenha mudado em pelo menos três
símbolos de entrada normais desde que o último erro foi detectado ou uma ação semântica foi executada
a macro Yyerrok. O analisador não deve chamar erro() quando YYERROR é executado.

A função macro YYRECOVERING deve retornar 1 se um erro de sintaxe for detectado e o
o analisador ainda não se recuperou totalmente dele. Caso contrário, zero será retornado.

Quando um erro de sintaxe é detectado pelo analisador, o analisador deve verificar se uma sintaxe anterior
erro foi detectado. Se um erro anterior foi detectado e se nenhum símbolo de entrada normal
foram deslocados desde que o erro anterior foi detectado, o analisador verifica se o
o símbolo de lookahead é um marcador final (ver Interface para que o Lexical Analista) Se for, o
o analisador deve retornar com um valor diferente de zero. Caso contrário, o símbolo de lookahead deve ser
descartado e a análise normal deve ser retomada.

Quando YYERROR é executado ou quando o analisador detecta um erro de sintaxe e nenhum erro anterior
foi detectado, ou pelo menos um símbolo de entrada normal foi alterado desde o anterior
erro foi detectado, o analisador deve retornar um estado de cada vez até que a pilha de análise seja
vazio ou o estado atual permite uma mudança erro. Se o analisador esvaziar a análise
pilha, ele deve retornar com um valor diferente de zero. Caso contrário, deve mudar erro e
em seguida, retome a análise normal. Se o analisador ler um símbolo de antevisão antes de o erro ser
detectado, esse símbolo ainda será o símbolo de antevisão quando a análise for retomada.

A macro Yyerrok em uma ação semântica deve fazer com que o analisador aja como se tivesse totalmente
recuperado de quaisquer erros anteriores. A macro yclearina deve fazer com que o analisador descarte
o token lookahead atual. Se o token lookahead atual ainda não foi lido,
yclearina não terá efeito.

A macro YYACCEPT fará com que o analisador retorne com o valor zero. A macro YYABORT
deve fazer com que o analisador retorne com um valor diferente de zero.

Interface para que o Lexical Analista
A yylex() função é uma função com valor inteiro que retorna um token número
representando o tipo de token lido. Se houver um valor associado ao token
devolvido por yylex() (veja a discussão de etiqueta acima), será atribuído ao
variável externa Yylval.

Se o analisador e yylex() discorda desses números de token, comunicação confiável
entre eles não pode ocorrer. Para literais (caractere de byte único), o token é simplesmente o
valor numérico do caractere no conjunto de caracteres atual. Os números de outros tokens
pode ser escolhido por yacc, ou escolhido pelo usuário. Em qualquer caso, o #define construir
de C é usado para permitir yylex() para retornar esses números simbolicamente. O #define declarações
são colocados no arquivo de código e no arquivo de cabeçalho, se esse arquivo for solicitado. O conjunto de
personagens permitidos por yacc em um identificador é maior do que o permitido por C. Token
nomes encontrados contendo tais caracteres não devem ser incluídos no #define declarações.

Se os números do token forem escolhidos por yacc, os tokens que não sejam literais serão atribuídos
números maiores que 256, embora nenhuma ordem esteja implícita. Um token pode ser atribuído explicitamente
um número seguindo sua primeira aparição na seção de declarações com um número.
Nomes e literais não definidos dessa maneira mantêm sua definição padrão. Todos os números de tokens
Assinado por yacc devem ser únicos e distintos dos números de token usados ​​para literais e
tokens atribuídos pelo usuário. Se números de tokens duplicados causam conflitos na geração do analisador,
yacc deve relatar um erro; caso contrário, não é especificado se a atribuição do token é
aceito ou um erro é relatado.

O final da entrada é marcado por um token especial chamado de marcador final, que tem um token
número que é zero ou negativo. (Esses valores são inválidos para qualquer outro token.) Todos
analisadores lexicais devem retornar zero ou negativo como um número simbólico ao atingir o final de
sua entrada. Se os tokens até, mas excluindo, o marcador final formam uma estrutura que
corresponde ao símbolo de início, o analisador deve aceitar a entrada. Se o marcador final for visto em
qualquer outro contexto, será considerado um erro.

Concluindo que o Agenda
Além de yyparse() e yylex(), As funções erro() e principal() são obrigados a
faça um programa completo. O aplicativo pode fornecer principal() e erro(), ou aqueles
rotinas podem ser obtidas no yacc biblioteca.

Yacc Biblioteca
As seguintes funções devem aparecer apenas no yacc biblioteca acessível através do −eu y
operando para c99; eles podem, portanto, ser redefinidos por um aplicativo em conformidade:

int principal(anular)
Esta função deve chamar yyparse() e saia com um valor não especificado. Outras ações
dentro desta função não são especificados.

int erro(const carbonizar *s)
Esta função deve escrever o argumento terminado em NUL para o erro padrão, seguido por
uma .

A ordem do −eu y e −eu l operandos dados a c99 é significativo; o aplicativo deve
ou fornecer o seu próprio principal() funcionar ou garantir que −eu y precede −eu l.

depuração que o Analisador
O analisador gerado por yacc deve ter recursos de diagnóstico que podem ser opcionalmente
habilitado em tempo de compilação ou em tempo de execução (se habilitado em tempo de compilação). O
a compilação do código de depuração em tempo de execução está sob o controle de YYDEBUG, um pré-processador
símbolo. Se YYDEBUG tiver um valor diferente de zero, o código de depuração deve ser incluído. Se é
valor é zero, o código não deve ser incluído.

Em analisadores onde o código de depuração foi incluído, o externo int yydebug pode ser
usado para ligar a depuração (com um valor diferente de zero) e desligar (valor zero) em tempo de execução. O
valor inicial de yydebug deve ser zero.

Quando -t for especificado, o arquivo de código deve ser construído de forma que, se YYDEBUG ainda não estiver
definido em tempo de compilação (usando o c99 −D Opção YYDEBUG, por exemplo), YYDEBUG deve
ser definido explicitamente como 1. Quando -t não for especificado, o arquivo de código deve ser construído de forma que,
se YYDEBUG ainda não estiver definido, ele deve ser definido explicitamente como zero.

O formato da saída de depuração não é especificado, mas inclui pelo menos informações suficientes
para determinar as ações de mudança e redução e os símbolos de entrada. Ele também fornece
informações sobre recuperação de erros.

Algoritmos
O analisador construído por yacc implementa um LALR(1) algoritmo de análise conforme documentado em
a literatura. Não é especificado se o analisador é orientado por tabela ou codificado diretamente.

Um analisador gerado por yacc nunca deve solicitar um símbolo de entrada de yylex() enquanto em um
estado onde as únicas ações além da ação de erro são reduções por uma única regra.

A literatura da teoria da análise sintática define esses conceitos.

Limites
A yacc utilitário pode ter várias tabelas internas. Os máximos mínimos para essas tabelas
são mostrados na tabela a seguir. O significado exato desses valores é implementação-
definiram. A implementação deve definir a relação entre esses valores e entre
eles e quaisquer mensagens de erro que a implementação possa gerar caso fique sem
espaço para qualquer estrutura interna. Uma implementação pode combinar grupos desses recursos
em um único pool, desde que o total disponível para o usuário não caia abaixo da soma
dos tamanhos especificados por esta seção.

Mesa: Interno Limites in yacc

┌──────────────┬─────────┬───────────────────────────── ─────┐
│ │ Mínimo │ │
│ Limitar │ Máximo │ Descrição │
├──────────────┼─────────┼───────────────────────────────────────────┼ ─────┤
│ {NTERMS} │ 126 │ Número de tokens. │
│ {NNONTERM} │ 200 │ Número de não terminais. │
│ {NPROD} │ 300 │ Número de regras. │
│ {NSTATES} │ 600 │ Número de estados. │
│ {MEMSIZE} │ 5200 │ Comprimento das regras. O total │
│ │ │ comprimento, em nomes (tokens e │
│ │ │ não terminais), de todos os │
│ │ │ regras da gramática. O │
│ │ │ lado esquerdo é contado para │
│ │ │ cada regra, mesmo que não seja │
│ │ │ repetido explicitamente, como │
│ │ │ especificado em Gramática Regras in │
│ │ │ yacc. │
│ {ACTSIZE} │ 4000 │ Número de ações. `` Ações '' │
│ │ │ aqui (e na descrição │
│ │ │ arquivo) consulte as ações do analisador │
│ │ │ (deslocar, reduzir e assim por diante) não │
│ │ │ para ações semânticas definidas em │
│ │ │ Gramática Regras in yacc. │
└──────────────┴─────────┴───────────────────────────────────────────┴ ─────┘

SAIR STATUS

Os seguintes valores de saída devem ser retornados:

0 Conclusão bem-sucedida.

> 0 Ocorreu um erro.

CONSEQUÊNCIAS OF ERROS

Se algum erro for encontrado, a execução é abortada e yacc sai com um status diferente de zero.
Arquivos de código parcial e arquivos de cabeçalho podem ser produzidos. As informações resumidas no
arquivo de descrição deve sempre ser produzido se o −v bandeira está presente.

A seguinte seções e guarante que os mesmos estão informativo.

APLICAÇÃO USO

Implementações históricas experimentam conflitos de nomes nos nomes yacc.tmp, yacc.acts,
yacc.debug, y.tab.c, y.tab.h e y.saída se mais de uma cópia de yacc está funcionando em um
único diretório de uma vez. O -b opção foi adicionada para superar este problema. O
problema relacionado de permitir múltiplos yacc analisadores a serem colocados no mesmo arquivo foi
endereçado adicionando um -p opção de substituir o codificado anteriormente yy prefixo variável.

A descrição do -p opção especifica o conjunto mínimo de nomes de funções e variáveis
que causam conflito quando vários analisadores estão vinculados. YYSTYPE não precisa ser
mudado. Em vez disso, o programador pode usar -b para fornecer os arquivos de cabeçalho para diferentes analisadores
nomes diferentes e, em seguida, o arquivo com o yylex() para um determinado analisador pode incluir o
cabeçalho para esse analisador. Nomes como yyclearrr não precisa ser mudado porque eles
são usados ​​apenas nas ações; eles não têm ligação. É possível que um
implementação tem outros nomes, sejam internos para implementar coisas como
yyclearrr, ou fornecendo recursos não padrão que deseja alterar com -p.

Operadores unários que são o mesmo token que um operador binário em geral precisam de seus
precedência ajustada. Isso é tratado pelo % prec símbolo consultivo associado ao
regra gramatical particular que define aquele operador unário. (Ver Gramática Regras in yacc.)
Os aplicativos não são obrigados a usar este operador para operadores unários, mas as gramáticas
que não requerem isso são raros.

EXEMPLOS

O acesso ao yacc biblioteca é obtida com operandos de pesquisa de biblioteca para c99. Para usar o
yacc biblioteca principal():

c99 y.tab.c −eu y

Tanto o lex biblioteca e o yacc biblioteca contém principal(). Para acessar o yacc principal():

c99 y.tab.c lex.aa.c −eu y −eu l

Isso garante que o yacc biblioteca é pesquisada primeiro, de modo que seu principal() é usado.

O histórico yacc bibliotecas contêm duas funções simples que são normalmente codificadas
pelo programador do aplicativo. Essas funções são semelhantes ao seguinte código:

#include
int principal (vazio)
{
externo int yyparse ();

setlocale (LC_ALL, "");

/ * Se o analisador a seguir for criado por lex, o
a aplicação deve ter cuidado para garantir que LC_CTYPE
e LC_COLLATE são definidos para o local POSIX. * /
(vazio) yyparse ();
retorno (0);
}

#includes

int yyerror (const char * msg)
{
(vazio) fprintf (stderr, "% s \ n", msg);
retorno (0);
}

JUSTIFICATIVA

As referências em Referenciado DOCUMENTOS pode ser útil na construção do analisador
gerador. O artigo referenciado de DeRemer e Pennello (junto com os trabalhos dele
referências) descreve uma técnica para gerar analisadores que estejam em conformidade com este volume de
POSIX.1‐2008. O trabalho nesta área continua a ser feito, portanto, os implementadores devem consultar
literatura atual antes de fazer qualquer nova implementação. O artigo original de Knuth é o
base teórica para este tipo de analisador, mas as tabelas que ele gera são impraticáveis
grande para gramáticas razoáveis ​​e não deve ser usado. O texto `` equivalente a '' é
intencional para garantir que as melhores tabelas que são LALR(1) pode ser gerado.

Tem havido confusão entre a classe de gramáticas, os algoritmos necessários para gerar
analisadores e os algoritmos necessários para analisar as linguagens. Eles são todos razoavelmente
ortogonal. Em particular, um gerador de analisador que aceita toda a gama de LR(1)
as gramáticas não precisam gerar uma tabela mais complexa do que aquela que aceita SLR(1) (um
classe relativamente fraca de gramáticas LR) para uma gramática que passa a ser SLR(1). Tal um
a implementação também não precisa reconhecer o caso; a compressão da tabela pode produzir o SLR(1)
mesa (ou até menor do que essa), sem reconhecer que a gramática é SLR(1) o
velocidade de um LR(1) o analisador para qualquer classe é mais dependente da representação da tabela e
compressão (ou a geração de código se um analisador direto é gerado) do que sobre a classe
da gramática que o gerador de tabelas lida.

A velocidade do gerador de analisador é um pouco dependente da classe de gramática que ele
alças. No entanto, os algoritmos do artigo original de Knuth para a construção de analisadores LR foram
julgado por seu autor como impraticavelmente lento naquela época. Embora LR completo seja mais
complexo do que LALR(1), à medida que as velocidades e os algoritmos do computador melhoram, a diferença (em termos
de tempo de execução de relógio de parede aceitável) está se tornando menos significativo.

Os potenciais autores são alertados de que o artigo referenciado de DeRemer e Pennello
citado anteriormente identifica um bug (uma simplificação excessiva do cálculo de LALR(1)
conjuntos lookahead) em alguns dos LALR(1) declarações de algoritmo que o precederam para
publicação. Eles devem ter tempo para procurar esse artigo, bem como as informações relevantes
trabalho, particularmente de Aho.

A -b opção foi adicionada para fornecer um método portátil para permitir yacc trabalhar em
vários analisadores separados no mesmo diretório. Se um diretório contém mais de um
yacc gramática, e ambas as gramáticas são construídas ao mesmo tempo (por, por exemplo, um
paralelo fazer programa), os resultados do conflito. Embora a solução não seja a prática histórica,
corrige uma deficiência conhecida nas implementações históricas. As mudanças correspondentes foram
feito para todas as seções que referenciam os nomes de arquivo y.tab.c (agora `` o arquivo de código ''),
y.tab.h (agora `` o arquivo de cabeçalho ''), e y.saída (agora `` o arquivo de descrição '').

A gramática para yacc a entrada é baseada na documentação do System V. A descrição textual
mostra lá que o ';' é obrigatório no final da regra. A gramática e o
implementação não exige isso. (O uso de C_IDENTIFICADOR faz com que uma redução ocorra em
O lugar certo.)

Além disso, nessa implementação, as construções como %símbolo pode ser encerrado por um
, mas isso não é permitido pela gramática. As palavras-chave como %símbolo pode
também aparecem em maiúsculas, o que novamente não é discutido. Na maioria dos lugares onde '%' é usado,
pode ser substituído, e há grafias alternativas para alguns dos símbolos
(por exemplo, %DEIXOU pode ser "% <" ou mesmo "\ <").

Historicamente,etiqueta> pode conter qualquer caractere, exceto '>', incluindo espaço em branco, no
implementação. No entanto, desde o etiqueta deve fazer referência a um membro do sindicato padrão ISO C, em
as implementações em conformidade com a prática precisam suportar apenas o conjunto de caracteres para ISO C
identificadores padrão neste contexto.

Algumas implementações históricas são conhecidas por aceitar ações que são encerradas por um
período. Implementações históricas geralmente permitem '$' em nomes. Uma implementação conforme
não precisa oferecer suporte a nenhum desses comportamentos.

Decidindo quando usar % prec ilustra a dificuldade em especificar o comportamento de yacc.
Pode haver situações em que o gramática não é, estritamente falando, um erro, e ainda assim
yacc não pode interpretá-lo inequivocamente. A resolução de ambigüidades na gramática pode
em muitos casos, pode ser resolvido com o fornecimento de informações adicionais, como o uso de %tipo or
%União declarações. Muitas vezes é mais fácil e geralmente produz um analisador menor para pegar
esta alternativa quando for apropriado.

O tamanho e o tempo de execução de um programa produzido sem o código de depuração em tempo de execução é
geralmente menor e um pouco mais rápido em implementações históricas.

Mensagens de estatísticas de várias implementações históricas incluem os seguintes tipos de
informações:

nTerminais / 512, n/ 300 não terminais
n/ 600 regras gramaticais, n/ 1500 estados
n deslocar / reduzir, n reduzir / reduzir conflitos relatados
n/ 350 conjuntos de trabalho usados
Memória: estados, etc. n/ 15000, analisador n/ 15000
n/ 600 conjuntos de lookahead distintos
n fechamentos extras
n entradas de turno, n exceções
n ir para entradas
n entradas salvas por goto padrão
Espaço do otimizador usado: entrada n/ 15000, saída n/ 15000
n entradas de mesa, n zero
Spread máximo: n, Deslocamento máximo: n

O relatório das tabelas internas no arquivo de descrição é deixado definido pela implementação
porque todos os aspectos desses limites também são definidos pela implementação. Algumas implementações
podem usar técnicas de alocação dinâmica e não têm valores-limite específicos para relatar.

O formato do y.saída arquivo não é fornecido porque a especificação do formato não foi
visto para melhorar a portabilidade de aplicativos. A lista destina-se principalmente a ajudar humanos
os usuários entendem e depuram o analisador; uso de y.saída por um script de aplicativo em conformidade
seria incomum. Além disso, as implementações não produziram uma saída consistente e nenhuma
formato popular era evidente. O formato selecionado pela implementação deve ser humano
legível, além do requisito de ser um arquivo de texto.

Os relatórios de erro padrão não são descritos especificamente porque raramente são úteis para
aplicativos em conformidade e não havia razão para restringir as implementações.

Algumas implementações reconhecem "= {" como equivalente a '{' porque aparece no histórico
documentação. Esta construção foi reconhecida e documentada como obsoleta há muito tempo,
1978, no referenciado Yacc: Ainda Outro Compilador-Compilador. Este volume de POSIX.1‐2008
optou por deixá-lo obsoleto e omiti-lo.

Os caracteres multibyte devem ser reconhecidos pelo analisador léxico e devolvidos como tokens.
Eles não devem ser retornados como literais de caracteres multibyte. O token erro que é usado
para recuperação de erro normalmente é atribuído o valor 256 na implementação histórica.
Assim, o valor de token 256, que é usado em muitos conjuntos de caracteres multibyte, não é
disponível para uso como o valor de um token definido pelo usuário.

FUTURO INSTRUÇÕES

Nenhum.

Use yaccposix online usando serviços onworks.net