Yacc
{ $$ = $1; }
が実行されて10がこのexprの値に代入されたのである。)
そしてテーブルに書かれていた状態番号10になる。
ここで'+'を読んでシフトし、状態16になってNUM《20》までシフトしたとき、
となるから、先と同様に規則6でNUMがexprに還元され
となる(以下、内部状態番号の変化は省略するが次々と遷移していく)。
ここで現在スタックの右端にある3トークン「expr '+' expr」が規則9(加算式)にマッチして還元が起こりそうに思えるかもしれないが、起こらない。先読みしている次のトークンが現在の「+」よりも優先順位が高い「*」なので還元はせず、シフトを行う(もし演算子優先順位を同列にしていたら還元が起こって先に加算をするであろう)。
NUM《30》を読んでシフトし
規則6で還元し、
ここで、右端の3トークンが
にマッチしていて、次のトークンは'-'であり、今度は遠慮なく還元が実行されてスタックから3個消えて、意味値が600と計算された左辺のグループexprが押し込まれるので、
のように2個分縮むことになる。
次に先読みしていた「-」を読み直す。ここの状態で右端の3トークンが
にマッチしていて、次のトークンは'-'であり、これも還元が実行されてスタックから3個消えて、意味値が10+600=610と計算されたグループexprが押し込まれるので、
開始記号("%start")、値型の集合("%union")、トークン(終端記号)宣言("%token")、グループ(非終端記号)宣言("%type")、 演算子優先順位指定("%left", "%right", "%nonassoc")などを、必要に応じて記述できるパートである。 例:

Bisonの場合はBison宣言部と呼ぶ。この場合さらに、衝突警告抑制("%expect")、純粋(再入可能)構文解析器指定("%pure_parser")ができる。
Yacc実行時になんらかの衝突が報告されるとき、および、上記パーサ実行時に正しいはずの入力がsyntax errorとなるときの主な対処方法には、次のようなものがある。
syntax error発生時に少なくともそのときのトークン値、状態スタック中の状態番号列およびソースファイル上の行番号・文字番号を出力するように作っておくことで、正確な調査を可能にする。
ある非終端記号から別の非終端記号に至る呼び出しパスが複数あれば、それは間違いなので直す(前述)。
「トークンまたは空である」といった非終端記号をひとつの構文右辺の中に複数並べることによって、衝突が生じていることがある。ひとつの右辺の中には省略のないトークンだけを使うようにする。そして、省略する、しないのすべての組合せは、右辺の種類として列挙してOR(|)結合する形に変更する。人間には等価ないし汚くなるように思えても、Yaccにとっては明瞭化になる。
リストのリストは、繰り返し要素にinなどの接頭辞的なトークンが伴わない定義などでは、要素がどの段階のリストに属するのかという曖昧性を生じる。この場合、リストの段階数を減らすように工夫して明瞭化する。
問題の非終端記号を使う場面ごとに、元が同じ文字列でも別のトークンから構成するように、定義を変更して明瞭化する。そのためにそのトークンを上述のようにLex段階で、場面に応じて変換し分ける。
パーサ実行時の期待外トークンで、あるトークンが複数の場面でどう絡んでいるかを調べるには、y.outputファイルでその状態番号を見つけて熟読し、その状態番号へ飛んでくる状態を1, 2段階さかのぼってたどってみると見えてくるものである。
これにより、ソーステキストの字句解析と構文解析を両方行って、規則のアクション部(あるいはさらにそれに呼ばれるユーザ作成のC言語関数)に書かれた計算の結果や、コンパイルの生成に使われる抽象構文木の構造体データ、あるいは各種表示が出力される、変換プログラムが完成する。GNUプロジェクトでは、Flex という名前で機能を提供している。
ちなみに、Yacc の上位機能をもちやや方式の異なる Java 言語向けジェネレータ JavaCC では、両方の定義・処理機能を併せもっている。Java向けではまた、字句解析器ジェネレータJFlexと構文解析器ジェネレータCUPとを組みあわせて用いることも行われている
Yacc と Lex はよく似た文法定義を持つ。組み使い、組で解説することがある。Lex と Yacc の機能は IEEE POSIX 1003.1-2008(かつては1003.2)で標準化している。