yaccposix - Online nel cloud

PROGRAMMA:

NOME

yacc — ancora un altro compilatore compilatore (SVILUPPO)

SINOSSI

sì, sì [-dltv] [-b prefisso_file] [-p sym_prefix] grammatica

DESCRIZIONE

I sì, sì l'utilità deve leggere una descrizione di una grammatica libera dal contesto in grammatica e scrivi C
codice sorgente, conforme allo standard ISO C, a un file di codice e, facoltativamente, intestazione
informazioni in un file di intestazione, nella directory corrente. Il codice sorgente generato deve
non dipendono da alcun comportamento indefinito, non specificato o definito dall'implementazione, eccetto in
casi in cui viene copiato direttamente dalla grammatica fornita, o nei casi che lo sono
documentato dall'attuazione. Il codice C deve definire una funzione e le relative routine
e macro per un automa che esegue un algoritmo di analisi che soddisfa i requisiti in
Algoritmi.

La forma e il significato della grammatica sono descritti nella sezione DESCRIZIONE ESTESA.

Il codice sorgente C e il file di intestazione devono essere prodotti in una forma adatta come input per il C
compilatore (vedi c99).

VERSIONI

I sì, sì l'utilità deve essere conforme al volume delle definizioni di base di POSIX.1‐2008, Sezione
12.2, Utilità Sintassi Linee Guida, ad eccezione della linea guida 9.

Sono supportate le seguenti opzioni:

-b prefisso_file
Usa il prefisso_file invece di y come prefisso per tutti i nomi di file di output. Il codice
filetto y.tab.c, il file di intestazione y.tab.h (creato quando -d è specificato), e il
file di descrizione y.uscita (creato quando -v è specificato), deve essere modificato in
prefisso_file.tab.c, prefisso_file.tab.he prefisso_file.produzione, Rispettivamente.

-d Scrivi il file di intestazione; per impostazione predefinita viene scritto solo il file di codice. Il #define
le istruzioni associano i codici token assegnati da sì, sì con l'utente dichiarato
nomi di token. Ciò consente file di origine diversi da y.tab.c per accedere al token
codici.

-l Produci un file di codice che non contenga nessuno #linea costrutti. Se questa opzione
non è presente, non è specificato se il file di codice o il file di intestazione contenga
#linea direttive. Questo dovrebbe essere usato solo dopo la grammatica e l'associato
le azioni sono completamente debuggate.

-p sym_prefix
Usa il sym_prefix invece di yy come prefisso per tutti i nomi esterni prodotti da
sì, sì. I nomi interessati devono includere le funzioni parse(); yylex(), e
yerror(), e le variabili yylval, ahicare yydebug. (Nel resto del
questa sezione, i sei simboli citati sono referenziati usando i loro nomi predefiniti
solo per comodità di notazione.) Anche i nomi locali possono essere influenzati dal -p
opzione; in ogni caso, il -p l'opzione non influirà #define simboli generati da
sì, sì.

-t Modificare le direttive di compilazione condizionale per consentire la compilazione del debug
codice nel file di codice. Le istruzioni di debug di runtime devono essere sempre contenute in
il file di codice, ma per impostazione predefinita le direttive di compilazione condizionale ne impediscono
compilazione.

-v Scrivere un file contenente una descrizione del parser e un rapporto sui conflitti
generato da ambiguità nella grammatica.

OPERANDI

È richiesto il seguente operando:

grammatica Un percorso di un file contenente istruzioni, di seguito chiamato grammatica, Per
quale deve essere creato un parser. Il formato per la grammatica è descritto nel
sezione DESCRIZIONE ESTESA.

STDIN

Non usato.

INGRESSO FILE

Il file grammatica deve essere un file di testo formattato come specificato nella DESCRIZIONE ESTESA
.

AMBIENTE VARIABILI

Le seguenti variabili d'ambiente influiranno sull'esecuzione di sì, sì:

LUNGO Fornire un valore predefinito per le variabili di internazionalizzazione non impostate o
nullo. (Vedi il volume Definizioni di base di POSIX.1-2008, Sezione 8.2,
Internazionalizzazione Variabili per il primato dell'internazionalizzazione
variabili utilizzate per determinare i valori delle categorie locali.)

LC_TUTTI Se impostato su un valore di stringa non vuoto, sovrascrive i valori di tutti gli altri
variabili di internazionalizzazione.

LC_CTYPE Determinare la localizzazione per l'interpretazione di sequenze di byte di dati di testo
come caratteri (ad esempio, caratteri a byte singolo anziché caratteri multibyte in
argomenti e file di input).

LC_MESSAGGI
Determinare la localizzazione che dovrebbe essere usata per influenzare il formato e il contenuto di
messaggi di diagnostica scritti nell'errore standard.

NLSPATH Determinare la posizione dei cataloghi dei messaggi per l'elaborazione di LC_MESSAGGI.

I LUNGO ed LC_ * variabili influenzano l'esecuzione del sì, sì utilità come indicato. Il principale()
funzione definita in Yacc Biblioteca chiamerà:

setlocale(LC_ALL, "")

e quindi il programma generato da sì, sì essere influenzato anche dal contenuto di questi
variabili in fase di esecuzione.

ASINCRONO EVENTI

Predefinito.

STDOUT

Non usato.

Stderr

Se vengono rilevati conflitti di spostamento/riduzione o riduzione/riduzione in grammatica, sì, sì deve scrivere a
segnalare tali conflitti allo standard error in un formato non specificato.

L'errore standard deve essere utilizzato anche per i messaggi di diagnostica.

USCITA FILE

Il file di codice, il file di intestazione e il file di descrizione devono essere file di testo. Tutti sono
descritto nelle sezioni seguenti.

Code Compila il
Questo file deve contenere il codice sorgente C per il parse() funzione. Deve contenere
codice per le varie azioni semantiche con sostituzione macro eseguita su di esse come
descritto nella sezione DESCRIZIONE ESTESA. Deve inoltre contenere una copia del #define
dichiarazioni nel file di intestazione. Se un %unione viene utilizzata la dichiarazione, la dichiarazione per
YYSTYPE deve essere incluso anche in questo file.

testata Compila il
Il file di intestazione deve contenere #define istruzioni che associano i numeri di token con il
nomi di token. Ciò consente ai file di origine diversi dal file di codice di accedere ai codici token.
Se un %unione viene utilizzata la dichiarazione, la dichiarazione per YYSTYPE e an esterno YYSTYPE yylval
anche la dichiarazione deve essere inclusa in questo file.

Descrizione Compila il
Il file di descrizione deve essere un file di testo contenente una descrizione della macchina a stati
corrispondente al parser, utilizzando un formato non specificato. Limiti per tabelle interne (vedi
Limiti) sono altresì segnalati, secondo modalità definite dall'attuazione. (Alcune implementazioni
possono utilizzare tecniche di allocazione dinamica e non hanno valori limite specifici da segnalare.)

EXTENDED DESCRIZIONE

I sì, sì il comando accetta una lingua utilizzata per definire una grammatica per una lingua di destinazione
essere analizzato dalle tabelle e dal codice generato da sì, sì. La lingua accettata da sì, sì come
la grammatica per la lingua di destinazione è descritta di seguito utilizzando il sì, sì lingua di input stessa.

L'input grammatica include regole che descrivono la struttura di input della lingua di destinazione e
codice da invocare quando queste regole sono riconosciute per fornire la semantica associata
azione. Il codice da eseguire deve apparire come corpi di testo che si intendono C-
codice della lingua. Questi corpi di testo non devono contenere trigrafi in lingua C. Il linguaggio C
si presume che le inclusioni formino una funzione corretta quando vengono elaborate da sì, sì nella sua uscita
File. Il codice così inserito deve essere eseguito durante il riconoscimento del
lingua di destinazione.

Data una grammatica, il sì, sì utility genera i file descritti in OUTPUT FILES
sezione. Il file di codice può essere compilato e collegato utilizzando c99. Se la dichiarazione e
le sezioni dei programmi del file di grammatica non includevano le definizioni di principale(); yylex(), e
yerror(), l'output compilato richiede il collegamento con versioni fornite esternamente di quelli
funzioni. Versioni predefinite di principale() e yerror() sono forniti in sì, sì biblioteca e
può essere collegato utilizzando il -l y operando a c99. sì, sì le interfacce della libreria non sono necessarie
supporta interfacce diverse da quelle predefinite yy prefisso del simbolo. L'applicazione fornisce
la funzione di analizzatore lessicale, yylex(); il lex l'utilità è specificamente progettata per
generare una tale routine.

Ingresso Lingua
L'applicazione deve garantire che ogni file di specifica sia composto da tre sezioni in
ordine: dichiarazioni, grammatica normee programmi, separati da doppio
caratteri ("%%"). Le sezioni dichiarazioni e programmi possono essere vuote. Se quest'ultimo è
vuoto, il precedente "%%" il segno che lo separa dalla sezione delle regole può essere omesso.

L'input è un testo in forma libera che segue la struttura della grammatica definita di seguito.

Lessicale Structure of , il Grammatica
Il , , e carattere deve essere ignorato, eccetto che il
applicazione garantisce che non appaiano in nomi o caratteri multicaratteri riservati
simboli. I commenti devono essere inclusi in "/* ... */", e può apparire ovunque sia un nome
valido.

I nomi sono di lunghezza arbitraria, composti da lettere, punti ("."), sottolinea ('_'), E
cifre non iniziali. Le lettere maiuscole e minuscole sono distinte. Applicazioni conformi
non deve usare nomi che iniziano con yy or YY poiché l' sì, sì parser utilizza tali nomi. Molti di
i nomi compaiono nell'output finale di sì, sì, e quindi dovrebbero essere scelti per conformarsi
con eventuali regole aggiuntive create dal compilatore C da utilizzare. In particolare appaiono
in #define dichiarazioni.

Un letterale consiste in un singolo carattere racchiuso tra virgolette singole. Tutto di
le sequenze di escape supportate per le costanti di carattere dalla norma ISO C devono essere
sostenuto da sì, sì.

Il rapporto con l'analizzatore lessicale è discusso in dettaglio di seguito.

L'applicazione deve garantire che il carattere NUL non sia utilizzato nelle regole grammaticali o
letterali.

Dichiarazioni Sezione
La sezione dichiarazioni viene utilizzata per definire i simboli utilizzati per definire la lingua di destinazione
e il loro rapporto con l'altro. In particolare, molte delle informazioni aggiuntive
richiesto per risolvere le ambiguità nella grammatica context-free per la lingua di destinazione è
fornito qui.

Generalmente sì, sì assegna la relazione tra i nomi simbolici che genera e la loro
valore numerico sottostante. La sezione dichiarazioni permette di controllare il
assegnazione di questi valori.

È anche possibile mantenere le informazioni semantiche associate ai token attualmente attivi
lo stack di analisi in un linguaggio C definito dall'utente unione, se i membri del sindacato sono
associati ai vari nomi della grammatica. La sezione dichiarazioni prevede
anche questo.

Il primo gruppo di dichiaratori di seguito accetta un elenco di nomi come argomenti. Quella lista può
facoltativamente essere preceduto dal nome di un membro dell'unione C (chiamato a etichetta sotto) che appare
entro '<' ed ">". (Come eccezione alle convenzioni tipografiche del resto di questo
volume di POSIX.1‐2008, in questo casoetichetta> non rappresenta una metavariabile, ma la
caratteri letterali parentesi angolari che circondano un simbolo.) L'uso di etichetta specifica che il
i token nominati su questa riga devono essere dello stesso tipo C del membro dell'unione a cui fa riferimento
etichetta. Questo è discusso più dettagliatamente di seguito.

Per gli elenchi utilizzati per definire i token, la prima apparizione di un determinato token può essere seguita da
un numero intero positivo (come una stringa di cifre decimali). In tal caso, il valore sottostante
numero assegnatogli a fini lessicali.

Di seguito dichiara Nome essere un segno:

%gettone [<etichetta>] Nome [numero] [Nome [numero]]...

If etichetta è presente, il tipo C per tutti i token su questa riga deve essere dichiarato come il tipo
referenziato da etichetta. Se un numero intero positivo, numero, segue a Nome, tale valore sarà
assegnato al token.

Di seguito dichiara Nome essere un token e gli assegna la precedenza:

%sinistra [<etichetta>] Nome [numero] [Nome [numero]]...
%Giusto [<etichetta>] Nome [numero] [Nome [numero]]...

In questa sezione possono apparire una o più righe, ciascuna che inizia con uno di questi simboli.
Tutti i token sulla stessa riga hanno lo stesso livello di precedenza e associatività; le linee
sono in ordine di precedenza crescente o forza vincolante. %sinistra denota che il
gli operatori su quella linea sono associativi di sinistra, e %Giusto similmente denota giusto
operatori associativi. Se etichetta è presente, deve dichiarare un tipo C per Nomeè come descritto
per %gettone.

Di seguito dichiara Nome essere un token e indica che non può essere utilizzato
associativamente:

%nonassoc [<etichetta>] Nome [numero] [Nome [numero]]...

Se il parser incontra l'uso associativo di questo token, segnala un errore. Se etichetta is
presente, deve dichiarare un tipo C per Nomeè come descritto per %gettone.

Di seguito si dichiara che membro del sindacato Nomes non sono terminali, e quindi è richiesto
avere un etichetta campo all'inizio:

%tipo <etichetta> Nome...

Poiché si occupa solo di non terminali, l'assegnazione di un numero di token o l'utilizzo di un letterale è
anche vietato. Se questo costrutto è presente, sì, sì esegue il controllo del tipo; se questo
costrutto non è presente, lo stack di analisi deve contenere solo il int tipo.

Ogni nome usato in grammatica non definito da a %gettone, %sinistra, %Giusto, o %nonassoc
si presume che la dichiarazione rappresenti un simbolo non terminale. Il sì, sì l'utilità deve segnalare
un errore per qualsiasi simbolo non terminale che non appare sul lato sinistro di almeno uno
regola grammaticale.

Una volta specificato il tipo, la precedenza o il numero di token di un nome, non deve essere
cambiato. Se la prima dichiarazione di un token non assegna un numero di token, sì, sì deve
assegnare un numero di token. Una volta effettuata questa assegnazione, il numero del token non deve essere modificato
per incarico esplicito.

I seguenti dichiaratori non seguono lo schema precedente.

Quanto segue dichiara il non-terminale Nome essere la inizia a simbolo, che rappresenta la
struttura più grande e più generale descritta dalle regole grammaticali:

%cominciare Nome

Per impostazione predefinita, è il lato sinistro della prima regola grammaticale; questa impostazione predefinita può essere
annullato con questa dichiarazione.

Di seguito si dichiara il sì, sì stack di valori per essere un'unione dei vari tipi di valori
desiderato.

%unione { stile di vita of unione (in C)}

Il corpo del sindacato non deve contenere token di pre-elaborazione con parentesi graffe sbilanciate.

Per impostazione predefinita, i valori restituiti dalle azioni (vedi sotto) e dall'analizzatore lessicale devono essere
di tipo int. sì, sì l'utilità tiene traccia dei tipi e deve inserire il corrispondente
nomi dei membri dell'unione per eseguire il controllo del tipo rigoroso del parser risultante.

In alternativa, dato che almeno unoetichetta> viene utilizzato il costrutto, l'unione può essere dichiarata
in un file di intestazione (che deve essere incluso nella sezione delle dichiarazioni utilizzando a #includere
costruire dentro %{ ed %}) e a typedef usato per definire il simbolo YYSTYPE da rappresentare
questa unione. L'effetto di %unione è fornire la dichiarazione di YYSTYPE direttamente da
, il sì, sì ingresso.

Le dichiarazioni e le definizioni in linguaggio C possono apparire nella sezione delle dichiarazioni, allegata
dai seguenti segni:

%{ ... %}

Queste istruzioni devono essere copiate nel file di codice e avere un ambito globale al suo interno, quindi
che possono essere utilizzati nelle regole e nelle sezioni del programma. Le dichiarazioni non devono contenere
"%}" al di fuori di un commento, di una stringa letterale o di una costante a più caratteri.

L'applicazione garantisce che la sezione delle dichiarazioni sia chiusa dal token %%.

Grammatica Regole in sì, sì
La sezione delle regole definisce la grammatica libera dal contesto che deve essere accettata dalla funzione sì, sì
genera e associa a tali regole azioni in linguaggio C e precedenze aggiuntive
informazione. La grammatica è descritta di seguito e segue una definizione formale.

La sezione delle regole è composta da una o più regole grammaticali. Una regola grammaticale ha la forma:

A : BODY ;

Il simbolo A rappresenta un nome non terminale, e BODY rappresenta una sequenza di zero o
Scopri di più Nomes, letterales, e semantico aziones che possono essere seguiti da optional
precedenza regolaS. Solo i nomi e i letterali partecipano alla formazione del
grammatica; le azioni semantiche e le regole di precedenza sono usate in altri modi. Il e
il sono sì, sì punteggiatura. Se ci sono più regole grammaticali successive con
lo stesso lato sinistro, il ('|') può essere utilizzato per evitare di riscrivere il
lato sinistro; in questo caso il appare solo dopo l'ultima regola. Il corpo
parte può essere vuota (o vuota di nomi e letterali) per indicare che il non-terminale
il simbolo corrisponde alla stringa vuota.

I sì, sì l'utilità assegna un numero univoco a ciascuna regola. Regole utilizzando la barra verticale
notazione sono regole distinte. Il numero assegnato alla regola compare nella descrizione
file.

Gli elementi che compongono un CORPO sono:

Nome, letterale
Queste formano le regole della grammatica: Nome è a token o non terminale;
letterale sta per se stesso (meno le virgolette richieste dal punto di vista lessicale).

semantico azione
Ad ogni regola grammaticale, l'utente può associare azioni da eseguire di volta in volta
la regola viene riconosciuta nel processo di input. (Nota che la parola "azione" può
fare riferimento anche alle azioni del parser: spostamento, riduzione e così via.)

Queste azioni possono restituire valori e possono ottenere i valori restituiti dal precedente
Azioni. Questi valori sono mantenuti in oggetti di tipo YYSTYPE (vedi %unione). Il
il valore del risultato dell'azione deve essere mantenuto nello stack di analisi con la mano sinistra
lato della regola, a cui accedere da altre riduzioni come parte della loro destra
lato. Usando iletichetta> informazioni fornite nella sezione dichiarazioni, le
codice generato da sì, sì può essere rigorosamente controllato dal tipo e contenere arbitrario
informazione. Inoltre, l'analizzatore lessicale può fornire gli stessi tipi di
valori per i token, se lo si desidera.

Un'azione è un'istruzione C arbitraria e come tale può eseguire input o output, call
sottoprogrammi e alterare le variabili esterne. Un'azione è una o più istruzioni C
racchiuso tra parentesi graffe '{' ed '}'. Le dichiarazioni non devono contenere
token di preelaborazione con parentesi graffe sbilanciate.

Alcune pseudo-variabili possono essere utilizzate nell'azione. Queste sono macro per l'accesso
a strutture dati note internamente a sì, sì.

$$ Il valore dell'azione può essere impostato assegnandolo a $$. Se tipo
la verifica è abilitata e il tipo di valore da assegnare non può essere
determinato, può essere generato un messaggio diagnostico.

$numero Si riferisce al valore restituito dal componente specificato dal
token numero nella parte destra di una regola, leggendo da sinistra a destra;
numero può essere zero o negativo. Se numero è zero o negativo, it
si riferisce ai dati associati al nome nello stack del parser
che precede il simbolo più a sinistra della regola corrente. (Questo è, "$ 0"
si riferisce al nome immediatamente precedente al nome più a sinistra nel
regola corrente da trovare nello stack del parser e "$-1" si riferisce a
simbolo a la sua sinistra.) Se numero si riferisce a un elemento oltre la corrente
punto nella regola, o oltre il fondo della pila, il risultato è
non definito. Se il controllo del tipo è abilitato e il tipo del valore da essere
assegnato non può essere determinato, può essere generato un messaggio di diagnostica.

$<etichetta>numero
Questi corrispondono esattamente ai simboli corrispondenti senza il etichetta
inclusione, ma consente un controllo rigoroso del tipo (e preclude gli indesiderati
conversioni di tipo). L'effetto è che la macro è espansa per l'uso etichetta
per selezionare un elemento dall'unione YYSTYPE (usando nomedati.tag).
Ciò è particolarmente utile se numero non è positivo.

$<etichetta>$ Questo impone al riferimento il tipo di membro dell'unione referenziato
by etichetta. Questa costruzione è applicabile quando un riferimento a una sinistra
il valore di contesto si verifica nella grammatica e fornisce sì, sì con un mezzo
per la selezione di un tipo.

Le azioni possono verificarsi ovunque in una regola (non solo alla fine); un'azione può accedere
valori restituiti dalle azioni alla sua sinistra e, a sua volta, il valore che restituisce può essere
accessibile da azioni alla sua destra. Un'azione che appare nel mezzo di una regola
equivale a sostituire l'azione con un nuovo simbolo non terminale e
aggiungendo una regola vuota con quel simbolo non terminale sul lato sinistro. Il
l'azione semantica associata alla nuova regola deve essere equivalente all'originale
azione. L'uso di azioni all'interno delle regole potrebbe introdurre conflitti che non sarebbero
altrimenti esiste.

Per impostazione predefinita, il valore di una regola deve essere il valore del primo elemento in essa contenuto.
Se il primo elemento non ha un tipo (in particolare nel caso di a
letterale) e il controllo del tipo è attivato da %tipo, verrà visualizzato un messaggio di errore.

precedenza
La parola chiave %prec può essere utilizzato per modificare il livello di precedenza associato a a
particolare regola grammaticale. Esempi di questo sono nei casi in cui un unario e binario
l'operatore ha la stessa rappresentazione simbolica, ma deve essere data in modo diverso
precedenti, o dove la gestione di una costruzione if-else ambigua è
necessario. Il simbolo riservato %prec può apparire immediatamente dopo il corpo di
la regola grammaticale e può essere seguito da un nome token o da un letterale. deve
fa sì che la precedenza della regola grammaticale diventi quella del token successivo
nome o letterale. L'azione per la regola nel suo insieme può seguire %prec.

Se segue una sezione di programma, l'applicazione deve garantire che le regole grammaticali siano
terminato da %%.

Programmi Sezione
I programmi sezione può includere la definizione dell'analizzatore lessicale yylex(), e qualsiasi
altre funzioni; ad esempio, quelli utilizzati nelle azioni specificate nelle regole grammaticali. Esso
non è specificato se la sezione dei programmi precede o segue le azioni semantiche in
il file di output; pertanto, se l'applicazione contiene definizioni di macro e
dichiarazioni destinate ad applicarsi al codice nelle azioni semantiche, le colloca
entro "%{ ... %}" nella sezione dichiarazioni

Ingresso Grammatica
Il seguente input per sì, sì produce un parser per l'input a sì, sì. Questa sintassi formale
ha la precedenza sulla descrizione della sintassi del testo precedente.

La struttura lessicale è definita in modo meno preciso; Lessicale Structure of , il Grammatica definisce
maggior parte dei termini. La corrispondenza tra i termini precedenti e i token sottostanti è la seguente
segue.

IDENTIFICATORE Questo corrisponde al concetto di Nome, dato in precedenza. Include anche
letterali come definiti in precedenza.

C_IDENTIFICATORE
Questo è un nome, e inoltre è noto per essere seguito da a . UN
letterale non può fornire questo token.

NUMERO Una stringa di cifre (un intero decimale non negativo).

TIPO, SINISTRA, MARK, LCURL, RCURL
Questi corrispondono direttamente a %tipo, %sinistra, %%, %{e %}.

{ ... } Questo indica il codice sorgente del linguaggio C, con la possibile inclusione di "$"
macro come discusso in precedenza.

/* Grammatica per , il ingresso a sì, sì */
/* Standard le voci. */
/* I i seguenti sono riconosciuto by , il lessicale analizzatore. */

%token IDENTIFIER /* Include identificatori e letterali */
%token C_IDENTIFIER /* identificatore (ma non letterale)
seguito da un :. */
%token NUMERO /* [0-9][0-9]* */

/* Parole riservate : %type=>TYPE %left=>LEFT, e così via */

%token SINISTRA DESTRA TOKEN NON ASSOC TIPO PREC INIZIA UNION

%token MARK /* Il segno %%. */
%token LCURL /* Il segno %{. */
%token RCURL /* Il segno %}. */

/* I caratteri letterali a 8 bit rappresentano se stessi; */
/* i token devono essere definiti per i caratteri multibyte. */

%specifica di partenza

%%

spec : defs MARK regole coda
;
coda: MARK
{
/* In questa azione, imposta il resto del file. */
}
| /* Vuoto; il secondo MARK è facoltativo. */
;
defs : /* Vuoto. */
| def def
;
def : INIZIO IDENTIFICATORE
| UNIONE
{
/* Copia la definizione dell'unione nell'output. */
}
| LCURL
{
/* Copia il codice C nel file di output. */
}
RCURL
| tag rword nlist
;
parola : TOKEN
| SINISTRA
| GIUSTO
| NON ASSOCIATO
| GENERE
;
tag : /* Vuoto: ID tag union opzionale. */
| '<' IDENTIFICATORE '>'
;
nlista : nmno
| nlist nmno
;
nmno : IDENTIFICATORE /* Nota: letterale non valido con tipo %. */
| NUMERO IDENTIFICATORE /* Nota: non valido con tipo %. */
;

/* Sezione regola */

regole : C_IDENTIFIER rbody prec
| le regole regolano
;
regola: C_IDENTIFIER rbody prec
| '|' rbody prec
;
rbody : /* vuoto */
| rbody IDENTIFICATORE
| atto del corpo
;
atto : '{'
{
/* Copia l'azione, traduce $$ e così via. */
}
'}'
;
prec : /* Vuoto */
| IDENTIFICATORE PREC
| IDENTIFICATORE PREC atto
| prec ';'
;

Conflitti
Il parser prodotto per una grammatica di input può contenere stati in cui si verificano conflitti. Il
i conflitti si verificano perché la grammatica non lo è LALR(1). Una grammatica ambigua contiene sempre
almeno una LALR(1) conflitto. Il sì, sì l'utilità risolverà tutti i conflitti, utilizzando l'uno o l'altro
regole predefinite o regole di precedenza specificate dall'utente.

I conflitti sono conflitti di spostamento/riduzione o di riduzione/riduzione dei conflitti. Uno spostamento/riduzione
il conflitto è dove, per un dato stato e simbolo di lookahead, sia un'azione di spostamento che un
ridurre l'azione sono possibili. Un conflitto di riduzione/riduzione è dove, per un dato stato e
simbolo lookahead, sono possibili riduzioni di due regole diverse.

Le regole seguenti descrivono come specificare quali azioni intraprendere quando si verifica un conflitto. Non
tutti i conflitti di spostamento/riduzione possono essere risolti con successo in questo modo perché il conflitto potrebbe
essere dovuto a qualcosa di diverso dall'ambiguità, quindi l'uso incauto di queste strutture può causare
la lingua accettata dal parser è molto diversa da quella voluta. Il
file di descrizione deve contenere informazioni sufficienti per comprendere la causa del
conflitto. Laddove l'ambiguità è la ragione per cui dovrebbero essere le regole predefinite o esplicite
adeguato per produrre un parser funzionante.

Le precedenze e le associazioni dichiarate (cfr Dichiarazioni Sezione) sono abituati a
risolvere i conflitti di analisi come segue:

1. Ad ogni regola grammaticale è associata una precedenza e un'associatività; è il
precedenza e associatività dell'ultimo token o letterale nel corpo della regola. Se
, il %prec viene utilizzata la parola chiave, sovrascrive questa impostazione predefinita. Alcune regole grammaticali potrebbero non esserlo
hanno sia la precedenza che l'associatività.

2. Se c'è un conflitto shift/reduce e sia la regola grammaticale che il simbolo di input
hanno la precedenza e l'associatività ad essi associate, allora il conflitto è risolto
a favore dell'azione (sposta o riduci) associata alla precedenza più alta. Se la
le precedenze sono le stesse, quindi si usa l'associatività; associativo sinistro implica
riduci, l'associativo destro implica lo spostamento e il non associativo implica un errore nel
stringa analizzata.

3. Quando c'è un conflitto spostamento/riduzione che non può essere risolto dalla regola 2, lo spostamento è
fatto. I conflitti risolti in questo modo vengono conteggiati nell'output diagnostico descritto in
Errore Manovrabilità .

4. Quando c'è un conflitto di riduzione/riduzione, una riduzione è fatta dalla regola grammaticale che
si verifica prima nella sequenza di input. I conflitti risolti in questo modo vengono conteggiati nel
uscita diagnostica descritta in Errore Manovrabilità .

I conflitti risolti per precedenza o associatività non devono essere conteggiati nel turno/riduzione
e ridurre/ridurre i conflitti segnalati da sì, sì su errore standard o in
file di descrizione.

Errore Manovrabilità
Il token errore deve essere riservato alla gestione degli errori. Il nome errore può essere utilizzato in
regole grammaticali. Indica i punti in cui il parser può recuperare da un errore di sintassi. Il
valore predefinito di errore deve essere 256. Il suo valore può essere modificato utilizzando a %gettone dichiarazione.
L'analizzatore lessicale non deve restituire il valore di errore.

Il parser deve rilevare un errore di sintassi quando si trova in uno stato in cui l'azione associata
con il simbolo lookahead è errore. Un'azione semantica può causare l'avvio del parser
gestione degli errori eseguendo la macro YYERROR. Quando viene eseguito YYERROR, il semantic
l'azione restituisce il controllo al parser. YYERROR non può essere utilizzato al di fuori di semantic
azioni.

Quando il parser rileva un errore di sintassi, normalmente chiama yerror() con il carattere
stringa "sintassi errore" come suo argomento. La chiamata non deve essere effettuata se il parser è fermo
recupero da un errore precedente quando viene rilevato l'errore. Il parser è considerato
si sta riprendendo da un errore precedente fino a quando il parser non si è spostato su almeno tre
simboli di input normali da quando è stato rilevato l'ultimo errore o è stata eseguita un'azione semantica
la macro sì. Il parser non deve chiamare yerror() quando viene eseguito YYERROR.

La funzione macro YYRECOVERING deve restituire 1 se è stato rilevato un errore di sintassi e il
il parser non si è ancora completamente ripreso. In caso contrario, verrà restituito zero.

Quando viene rilevato un errore di sintassi dal parser, il parser deve verificare se una sintassi precedente
errore è stato rilevato. Se è stato rilevato un errore precedente e se nessun simbolo di input normale
sono stati spostati da quando è stato rilevato l'errore precedente, il parser controlla se il
il simbolo lookahead è un endmarker (vedi Interfaccia a , il Lessicale Analyzer). Se lo è, il
parser deve restituire un valore diverso da zero. In caso contrario, il simbolo lookahead deve essere
scartato e l'analisi normale riprenderà.

Quando viene eseguito YYERROR o quando il parser rileva un errore di sintassi e nessun errore precedente
è stato rilevato, o almeno un simbolo di ingresso normale è stato spostato rispetto al precedente
è stato rilevato un errore, il parser deve tornare indietro di uno stato alla volta fino a quando lo stack di analisi è
vuoto o lo stato corrente consente uno shift over errore. Se il parser svuota il parse
stack, deve restituire un valore diverso da zero. In caso contrario, si sposterà su errore ed
quindi riprendere l'analisi normale. Se il parser legge un simbolo lookahead prima che l'errore fosse
rilevato, quel simbolo deve essere ancora il simbolo lookahead quando l'analisi viene ripresa.

La macro sì in un'azione semantica farà sì che il parser agisca come se avesse completamente
recuperato da eventuali errori precedenti. La macro aaclearin farà sì che il parser si scarti
il token lookahead corrente. Se il token lookahead corrente non è stato ancora letto,
aaclearin non avrà effetto.

La macro YYACCEPT farà sì che il parser restituisca con il valore zero. La macro YYABORT
farà sì che il parser ritorni con un valore diverso da zero.

Interfaccia a , il Lessicale Analyzer
I yylex() la funzione è una funzione a valori interi che restituisce a token numero
che rappresenta il tipo di token letto. Se c'è un valore associato al token
restituito da yylex() (vedi la discussione di etichetta sopra), sarà assegnato al
variabile esterna yylval.

Se il parser e yylex() non sono d'accordo su questi numeri di token, comunicazione affidabile
tra loro non può avvenire. Per i letterali (caratteri a byte singolo), il token è semplicemente il
valore numerico del carattere nel set di caratteri corrente. I numeri per altri token
può essere scelto da sì, sì, o scelto dall'utente. In entrambi i casi, il #define costruire
di C viene utilizzato per consentire yylex() per restituire simbolicamente questi numeri. Il #define dichiarazioni
vengono inseriti nel file di codice e nel file di intestazione se tale file è richiesto. Il set di
caratteri consentiti da sì, sì in un identificatore è maggiore di quello consentito da C. Token
i nomi che contengono tali caratteri non devono essere inclusi nel #define dichiarazioni.

Se i numeri token sono scelti da sì, sì, i token diversi dai letterali devono essere assegnati
numeri maggiori di 256, sebbene non sia implicito alcun ordine. Un token può essere assegnato esplicitamente
un numero seguendo la sua prima apparizione nella sezione delle dichiarazioni con un numero.
Nomi e letterali non definiti in questo modo mantengono la loro definizione predefinita. Tutti i numeri token
assegnato da sì, sì deve essere unico e distinto dai numeri token utilizzati per i letterali e
token assegnati dall'utente. Se i numeri di token duplicati causano conflitti nella generazione del parser,
sì, sì segnala un errore; in caso contrario, non è specificato se l'assegnazione del token è
accettato o viene segnalato un errore.

La fine dell'input è contrassegnata da uno speciale token chiamato marcatore finale, che ha un token
numero che è zero o negativo. (Questi valori non sono validi per nessun altro token.) Tutti
gli analizzatori lessicali devono restituire zero o negativo come numero token al raggiungimento della fine di
il loro ingresso. Se i token fino a, ma escludendo, l'endmarker formano una struttura che
corrisponde al simbolo di avvio, il parser accetterà l'input. Se il marcatore finale è visto in
qualsiasi altro contesto, sarà considerato un errore.

Completamento , il Programma
Oltre parse() e yylex(), le funzioni yerror() e principale() sono tenuti a
fare un programma completo. L'applicazione può fornire principale() e yerror(), o quelli
le routine possono essere ottenute da sì, sì biblioteca.

Yacc Biblioteca
Le seguenti funzioni appariranno solo nel sì, sì biblioteca accessibile tramite il -l y
operando a c99; possono quindi essere ridefiniti da una domanda conforme:

int principale(nulla)
Questa funzione deve chiamare parse() ed esce con un valore non specificato. Altre azioni
all'interno di questa funzione non sono specificati.

int yerror(const serbatoio *s)
Questa funzione deve scrivere l'argomento con terminazione NUL nell'errore standard, seguito da
un .

L'ordine del -l y ed -l l operandi dati a c99 è significativo; la domanda deve
o fornire il proprio principale() funzionare o garantire che -l y precede -l l.

Debug , il parser
Il parser generato da sì, sì deve avere strutture diagnostiche al suo interno che possono essere facoltativamente
abilitato in fase di compilazione o in fase di esecuzione (se abilitato in fase di compilazione). Il
la compilazione del codice di debug di runtime è sotto il controllo di YYDEBUG, un preprocessore
simbolo. Se YYDEBUG ha un valore diverso da zero, il codice di debug deve essere incluso. Se è
valore è zero, il codice non deve essere incluso.

Nei parser in cui è stato incluso il codice di debug, il file external int yydebug può essere
utilizzato per attivare (con un valore diverso da zero) e disattivare (con un valore zero) il debug in fase di esecuzione. Il
valore iniziale di yydebug deve essere zero.

Quando -t è specificato, il file di codice deve essere costruito in modo tale che, se YYDEBUG non lo è già
definito in fase di compilazione (usando il c99 −D opzione YYDEBUG, ad esempio), YYDEBUG deve
essere impostato esplicitamente su 1. Quando -t non è specificato, il file di codice deve essere costruito in modo tale che,
se YYDEBUG non è già definito, deve essere impostato esplicitamente a zero.

Il formato dell'output di debug non è specificato ma include almeno informazioni sufficienti
per determinare le azioni di spostamento e riduzione e i simboli di input. Fornisce anche
informazioni sul ripristino degli errori.

Algoritmi
Il parser costruito da sì, sì implementa e LALR(1) algoritmo di analisi come documentato in
la letteratura. Non è specificato se il parser è guidato da una tabella o codificato direttamente.

Un parser generato da sì, sì non deve mai richiedere un simbolo di input da yylex() mentre in a
stato in cui le uniche azioni diverse dall'azione di errore sono le riduzioni di una singola regola.

La letteratura sulla teoria del parsing definisce questi concetti.

Limiti
I sì, sì utility può avere diverse tabelle interne. I massimi minimi per queste tabelle
sono riportati nella tabella seguente. Il significato esatto di questi valori è implementazione-
definito. L'attuazione definisce la relazione tra questi valori e tra
loro e qualsiasi messaggio di errore che l'implementazione potrebbe generare se dovesse esaurirsi
spazio per qualsiasi struttura interna. Un'implementazione può combinare gruppi di queste risorse
in un unico pool purché il totale a disposizione dell'utente non scenda al di sotto della somma
delle dimensioni specificate da questa sezione.

Tabella: Interno Limiti in sì, sì

┌────────────────────────────────────────────────────────── ─────┐
│ │ Minimo │ │
│ Limitare │ Massimo │ Descrizione │
? ?
│{NTERMS} │ 126 │ Numero di token. ?
│{NNOTERM} │ 200 │ Numero di non terminali. ?
│{NPROD} │ 300 │ Numero di regole. ?
│{NSTATES} │ 600 │ Numero di stati. ?
│{MEMSIZE} │ 5200 │ Lunghezza delle regole. Il totale
│ │ │ lunghezza, nei nomi (token e │
│ │ │ non terminali), di tutti i │
│ │ │ regole della grammatica. il
│ │ │ Il lato sinistro viene contato per │
│ │ │ ogni regola, anche se non lo è │
│ │ │ ripetuto esplicitamente, come │
│ │ │ specificato in Grammatica Regole in │
│ │ │ sì, sì. ?
│{ACTSIZE} │ 4000 │ Numero di azioni. ``Azioni'' │
│ │ │ qui (e nella descrizione │
│ │ │ file) fare riferimento alle azioni del parser │
│ │ │ (sposta, riduci e così via) non │
│ │ │ alle azioni semantiche definite in │
│ │ │ Grammatica Regole in sì, sì. ?
? ?

EXIT STATUS

Devono essere restituiti i seguenti valori di uscita:

0 Completamento riuscito.

>0 Si è verificato un errore.

CONSEGUENZE OF ERRORI

Se si verificano errori, l'esecuzione viene interrotta e sì, sì esce con uno stato diverso da zero.
Possono essere prodotti file di codice parziali e file di intestazione. Le informazioni di riepilogo nel
il file di descrizione deve essere sempre prodotto se il -v bandiera è presente.

I i seguenti sezioni sono Informativo.

APPLICAZIONI USO

Le implementazioni storiche presentano conflitti di nomi sui nomi yacc.tmp, yacc.atti,
yacc.debug, y.tab.c, y.tab.he y.uscita se più di una copia di sì, sì sta correndo in un
singola directory alla volta. Il -b l'opzione è stata aggiunta per superare questo problema. Il
problema correlato di consentire più sì, sì parser da inserire nello stesso file era
affrontato aggiungendo a -p opzione per sovrascrivere il precedente hardcoded yy prefisso variabile.

La descrizione di -p opzione specifica l'insieme minimo di nomi di funzioni e variabili
che causano conflitti quando più parser sono collegati tra loro. YYSTYPE non ha bisogno di essere
cambiato. Invece, il programmatore può usare -b per fornire i file di intestazione per diversi parser
nomi diversi, quindi il file con il yylex() per un dato parser può includere il
intestazione per quel parser. Nomi come aaclearerr non hanno bisogno di essere cambiati perché loro
sono usati solo nelle azioni; non hanno collegamento. È possibile che an
l'implementazione ha altri nomi, sia interni per implementare cose come
aaclearerr, o fornendo funzionalità non standard con cui desidera cambiare -p.

Gli operatori unari che sono lo stesso token di un operatore binario in generale necessitano del loro
precedenza regolata. Questo è gestito dal %prec simbolo di avviso associato al
particolare regola grammaticale che definisce quell'operatore unario. (Vedere Grammatica Regole in sì, sì.)
Non è necessario che le applicazioni utilizzino questo operatore per gli operatori unari, ma le grammatiche
che non lo richiedono sono rari.

ESEMPI

Accesso al sì, sì la libreria si ottiene con gli operandi di ricerca della libreria a c99. Per usare il
sì, sì biblioteca principale†

c99 y.tab.c -l y

Entrambe le lex biblioteca e il sì, sì libreria contiene principale(). Per accedere al sì, sì principale†

c99 y.tab.c lex.aa.c -l y -l l

Ciò garantisce che il sì, sì la libreria viene cercata per prima, in modo che sia principale() si usa.

Lo storico sì, sì le librerie hanno contenuto due semplici funzioni che normalmente sono codificate
dal programmatore dell'applicazione. Queste funzioni sono simili al codice seguente:

#includere
int principale (vuoto)
{
esterno int yyparse();

setlocale(LC_ALL, "");

/* Se il seguente parser è uno creato da lex, il
l'applicazione deve fare attenzione per garantire che LC_CTYPE
e LC_COLLATE sono impostati sulla locale POSIX. */
(vuoto) yyparse();
ritorno (0);
}

#includere

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

FONDAMENTO LOGICO

I riferimenti in di riferimento Documenti può essere utile nella costruzione del parser
Generatore. Il citato articolo di DeRemer e Pennello (insieme alle opere
riferimenti) descrive una tecnica per generare parser conformi a questo volume di
POSIX.1‐2008. Il lavoro in questo settore continua a essere svolto, quindi gli implementatori dovrebbero consultare
letteratura corrente prima di fare nuove implementazioni. L'articolo originale di Knuth è il
base teorica per questo tipo di parser, ma le tabelle che genera non sono pratiche
grande per grammatiche ragionevoli e non dovrebbe essere usato. La dicitura "equivalente a" è
intenzionale per assicurare che i migliori tavoli che sono LALR(1) può essere generato.

C'è stata confusione tra la classe delle grammatiche, gli algoritmi necessari per generare
parser e gli algoritmi necessari per analizzare le lingue. Sono tutti ragionevolmente
ortogonale. In particolare, un generatore di parser che accetta l'intera gamma di LR(1)
le grammatiche non hanno bisogno di generare una tabella più complessa di una che accetti SLR(1) (a
classe relativamente debole di grammatiche LR) per una grammatica che sembra essere SLR(1). Come un
nemmeno l'attuazione deve riconoscere il caso; la compressione della tabella può produrre il SLR(1)
tabella (o anche una più piccola di quella) senza riconoscere che la grammatica è SLR(1). Il
velocità di an LR(1) il parser per qualsiasi classe dipende maggiormente dalla rappresentazione della tabella e
compressione (o la generazione del codice se viene generato un parser diretto) che sulla classe
di grammatica che gestisce il generatore di tabelle.

La velocità del generatore di parser dipende in qualche modo dalla classe di grammatica che è
maniglie. Tuttavia, gli algoritmi originali dell'articolo di Knuth per la costruzione di parser LR erano
giudicato dal suo autore come impraticabile lento in quel momento. Anche se full LR è più
complesso di LALR(1), con il miglioramento della velocità e degli algoritmi del computer, la differenza (in termini
di tempo di esecuzione accettabile dell'orologio da parete) sta diventando meno significativo.

Si avvisano i potenziali autori che il citato articolo di DeRemer e Pennello
precedentemente citato identifica un bug (una semplificazione eccessiva del calcolo di LALR(1)
set lookahead) in alcuni dei LALR(1) istruzioni dell'algoritmo che l'hanno preceduto a
pubblicazione. Dovrebbero prendersi il tempo per cercare quel documento, così come l'attuale rilevante
lavoro, in particolare di Aho.

I -b è stata aggiunta un'opzione per fornire un metodo portatile per consentire sì, sì Lavorare su
più parser separati nella stessa directory. Se una directory ne contiene più di uno
sì, sì grammatica, ed entrambe le grammatiche sono costruite allo stesso tempo (da, per esempio, a
parallelo make programma), risultati di conflitto. Sebbene la soluzione non sia la pratica storica,
corregge una nota carenza nelle implementazioni storiche. I cambiamenti corrispondenti sono stati
fatto a tutte le sezioni che facevano riferimento ai nomi dei file y.tab.c (ora ``il file di codice''),
y.tab.h (ora ``il file di intestazione''), e y.uscita (ora ``il file di descrizione'').

La grammatica per sì, sì l'input si basa sulla documentazione di System V. La descrizione testuale
mostra lì che il ';' è richiesto alla fine della regola. La grammatica e il
implementazione non richiedono questo. (L'impiego di C_IDENTIFICATORE fa sì che si verifichi una riduzione in
il posto giusto.)

Inoltre, in tale implementazione, i costrutti come %gettone può essere terminato da a
, ma ciò non è consentito dalla grammatica. Le parole chiave come %gettone può
appaiono anche in maiuscolo, che di nuovo non viene discusso. Nella maggior parte dei posti dove '%' si usa,
può essere sostituito, e ci sono grafie alternative per alcuni dei simboli
(per esempio, %SINISTRA può essere "%<" o addirittura "\<").

Storicamente,etichetta> può contenere qualsiasi carattere tranne ">", compreso lo spazio bianco, nel
implementazione. Tuttavia, dal momento che etichetta deve fare riferimento a un membro del sindacato standard ISO C, in
le implementazioni conformi alla pratica devono supportare solo il set di caratteri per ISO C
identificatori standard in questo contesto.

È noto che alcune implementazioni storiche accettano azioni terminate da a
periodo. Le implementazioni storiche spesso consentono "$" nei nomi. Un'implementazione conforme
non ha bisogno di supportare nessuno di questi comportamenti.

Decidere quando usarlo %prec illustra la difficoltà nello specificare il comportamento di sì, sì.
Ci possono essere situazioni in cui il grammatica non è, a rigor di termini, in errore, eppure
sì, sì non può interpretarlo in modo univoco. La risoluzione delle ambiguità nella grammatica può
in molti casi essere risolti fornendo informazioni aggiuntive, come l'utilizzo di %tipo or
%unione dichiarazioni. Spesso è più facile e di solito produce un parser più piccolo da prendere
questa alternativa quando è opportuno.

La dimensione e il tempo di esecuzione di un programma prodotto senza il codice di debug di runtime è
solitamente più piccolo e leggermente più veloce nelle implementazioni storiche.

I messaggi statistici di diverse implementazioni storiche includono i seguenti tipi di
informazioni:

n/512 terminali, n/300 non terminali
n/600 regole grammaticali, n/1500 stati
n sposta/riduci, n ridurre/ridurre i conflitti segnalati
n/350 set di lavoro usati
Memoria: stati, ecc. n/15000, analizzatore n/ 15000
n/600 distinti lookahead set
n chiusure extra
n voci di turno, n eccezioni
n vai alle voci
n voci salvate per impostazione predefinita
Spazio ottimizzato utilizzato: input n/15000, uscita n/ 15000
n voci della tabella, n zero
Diffusione massima: n, Scostamento massimo: n

Il report delle tabelle interne nel file di descrizione viene lasciato definito dall'implementazione
perché tutti gli aspetti di questi limiti sono definiti anche dall'implementazione. Alcune implementazioni
possono utilizzare tecniche di allocazione dinamica e non hanno valori limite specifici da segnalare.

Il formato del file y.uscita il file non viene fornito perché la specifica del formato non è stata fornita
visto per migliorare la portabilità delle applicazioni. L'elenco è principalmente destinato ad aiutare l'uomo
gli utenti comprendono ed eseguono il debug del parser; uso di y.uscita da uno script dell'applicazione conforme
sarebbe insolito. Inoltre, le implementazioni non hanno prodotto un output coerente e non
il formato popolare era evidente. Il formato selezionato dall'implementazione dovrebbe essere umano-
leggibile, oltre al requisito che sia un file di testo.

I rapporti di errore standard non sono descritti in modo specifico perché sono raramente utili per
applicazioni conformi e non c'era motivo di limitare le implementazioni.

Alcune implementazioni riconoscono "={" come equivalente a '{' perché appare in storico
documentazione. Questa costruzione è stata riconosciuta e documentata come obsoleta già da
1978, nella citata Yacc: ancora Un altro Compilatore-Compilatore. Questo volume di POSIX.1‐2008
ha scelto di lasciarlo obsoleto e di ometterlo.

I caratteri multibyte dovrebbero essere riconosciuti dall'analizzatore lessicale e restituiti come token.
Non devono essere restituiti come letterali di caratteri multibyte. Il token errore quello è usato
per il ripristino degli errori viene normalmente assegnato il valore 256 nell'implementazione storica.
Pertanto, il valore del token 256, utilizzato in molti set di caratteri multibyte, non lo è
disponibile per l'uso come valore di un token definito dall'utente.

FUTURE INDICAZIONI

Nessuno.

Usa yaccposix online utilizzando i servizi onworks.net