hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
三芝区 歴史
三芝区は古くは平埔族の支族であるケタガラン族の集落ヴァヴイ（豚の意味）社であった。
漢人の居住が開始された時期は不明だが、清の乾隆時代（18世紀中ごろから後半）頃に始まったと考えられている。旧称は「小鶏籠社」であったが、当時の支配者・清朝によって1875年に雅字である「小基隆」と改められた。この呼称は現在でも使用されている。芝蘭三堡に属していたことから、1920年の地方制度実施時に三芝庄と改称された。
2010年に台北県が直轄市の新北市に昇格する際、三芝郷から三芝区に改称された。
三芝区 交通
その他、台北捷運淡水駅、台鉄縦貫線基隆駅などからバスが多数出ている。
石門区
石門区（シーメン/せきもん-く）は台湾新北市の市轄区。
石門区 地理
石門区は新北市北端に位置し、東は金山区と、西は三芝区と、南は台北市士林区竹子湖とそれぞれ接し、北側は海に面している。
石門区 歴史
石門の名称は清初の1694年に鄭開極により著された『福建通志』巻5 山川誌の「石門山、旗干石西、一石中空如円門、故名」の記述が初見である。道同に石門迅荘と改称され滬尾水師営に帰属した。1871年には『淡水庁誌』の中で「海岸石門」が「淡水外八景」に数えられている。
日本統治時代の1920年、台湾に「街庄制」が施行され、石門地区は「石門庄」と命名された。1934年、海蝕作用で形成された石門洞が天然記念物に指定されている。
戦後に「石門郷」と改編された。2010年12月25日には台北県が新北市に改編されたことに伴い石門区と改編され現在に至っている。
Yacc
Yacc（英: yet another compiler compiler、ヤック）はパーサジェネレータの一つである。1970年代にAT&TでUNIX用にスティーヴン・カーティス・ジョンソンが開発した。
Yacc 概要
Yacc は yet another compiler compiler（またひとつのコンパイラコンパイラ）に由来する。コンピュータ黎明期には「自動プログラミング」と呼ばれたプログラミング言語処理系の技術の進展の方向として、当時、機械語プログラムを生成するコンパイラの次はコンパイラを生成するコンパイラコンパイラ（コンパイラジェネレータ）であろう、ということで盛んに研究がされており、そのためコンパイラコンパイラを名乗る研究が他にもあれこれ存在した。
パーサはコンパイラの全てではないので、コンパイラコンパイラと呼ぶには Yacc のようなパーサジェネレータは不足と言えなくもないが、特段意識されることは少ない。
まず一般的なコンパイラの構成について簡単に説明する。
ソースコードを中間表現あるいは機械語に変換するコンパイラは、ソースコードを入力として受け取り、構文木を構築して出力する構文解析部(A)と、その構文木を入力として受け取り、目的の中間表現ないし機械語のコードを生成して出力するコード生成部(B)からなる。
Yacc 概要
このうち構文解析部(A)は、文字列からトークンを切り出しトークン列とする字句解析器（レキシカルアナライザ、トークナイザ、スキャナ、図のA-1)と、構文規則に従ってトークン列に対し構文解析をおこない、構文木を出力する（狭義の）構文解析器（パーサ，パーザ、図のA-2)から成る。（必ずしもこのようにする必要はないが、典型的な構成としてはこのようにする）
構文解析器は直接書くこともできるが、煩雑になる部分があり、特にボトムアップ構文解析のプログラムを手で書くのは現実的ではない。そういった構文解析器を、機械可読な構文規則群から自動生成してくれるツールがパーサジェネレータである。YaccはLALR、通常LALR(1)の構文解析器を生成する。
Yacc はBNF（バッカス・ナウア記法）に似た構文規則を入力として受け取り、それに基づいて構文解析器を自動生成する。
Yacc の生成する構文解析器は解析テーブルとそれを用いるプログラムから構成される。構文解析手法はLALRである。
Yacc 概要
LALR法とは、ボトムアップ構文解析に属する強力なLR法に制限を加えた手法である（Lは入力を左から読むこと、Rは右端導出、その後に付くことのある(1)のような数字は先読みするトークン数（文字数ではない）が1個、を意味する）。コンパクトな解析テーブルでありながらC言語、Javaなど多くのプログラミング言語の構文解析器を実装することができる。アクション内で先読みを行うことでLALR(k)の文法に対応させることも不可能ではないが、普通はLALR(1)の構文解析器を生成する。
Yacc 概要
構文解析器(A-2)に解析を数字や英字や空白などの1文字単位で行わせると、複雜になりすぎる．しかし、人間が英文から英単語やカッコなどの記号列を、区切り文字（たとえば空白、タブ、改行、コンマ、終止符）やその列を目印に抽出して意味を判断しているのと同様の発想ができる。すなわち、区切り記号列でソースを切っていくと、「print」のような語、「1999」のような10進数、「"Hello, World."」といった文字リテラル、「++」といった演算子、「}」や「;」など意味のある区切り文字など、各種の文字列が取り出せる。これをトークンという。ここまでの下位の文法処理を上記字句解析器(A-1)に行わせ、一方、構文解析器(A-2)はトークンから出発して句、文、ブロック、プログラムなどを認識する上位の文法処理に専念させる。この分業化により、それぞれの定義と処理が簡潔になった。
Yacc には構文解析器の機能しかないが、特定の名前の未実装関数 yylex を呼んでトークンを毎度要求する。この字句解析器関数 yylex を作って動的にトークンを生成して、1回呼ばれるごとに1個のトークン種類を戻り値で返してやればよい。さらにそれが数値や文字列のように意味値をもつトークンのときは、意味値も変数 yylval にセットして同時に返す。ユーザはこの字句解析器関数 yylex の処理を実装することになる。
Yacc 概要
字句解析器(A-1)のほうも、合理的な開発を目的とし、Yacc に似た規則定義を与えれば字句解析器を自動生成してくれる便利な道具として、Lexや Flexなどのレキシカルアナライザジェネレータがある。
そこで Lex などの字句解析器生成ツールを利用するなら、それに字句文法定義を与えて生成させたC言語ソースである字句解析器が yylex 関数を含んでいるので、Cコンパイルで Yacc 出力と一緒にそれをリンクして組み込む。これにより、ソーステキストの字句解析と構文解析を両方行って、規則のアクション部（あるいはさらにそれに呼ばれるユーザ作成のC言語関数）に書かれた計算の結果や、コンパイルの生成に使われる抽象構文木の構造体データ、あるいは各種表示が出力される、変換プログラムが完成する。GNUプロジェクトでは、Flex という名前で機能を提供している。
ちなみに、Yacc の上位機能をもちやや方式の異なる Java 言語向けジェネレータ JavaCC では、両方の定義・処理機能を併せもっている。Java向けではまた、字句解析器ジェネレータJFlexと構文解析器ジェネレータCUPとを組みあわせて用いることも行われている
Yacc 概要
Yacc と Lex はよく似た文法定義を持つ。組み使い、組で解説することがある。Lex と Yacc の機能は IEEE POSIX 1003.1-2008（かつては1003.2）で標準化している。
Yaccは古典的なコンパイラコンパイラでありながら人気があり、今でもよく産業用や教育用に使われる。コンパイラを開発する目的に限らず、独自の設定ファイルの解析、プログラミング言語コンバータ開発、簡易電卓の例題による学習などに使われている。
YaccはほとんどのUNIXシステムで、デフォルトのパーサジェネレータとして利用可能だった。Yaccと上位互換を持つソフトとして、よく使われているGNUプロジェクトのBisonをはじめ、Barkeley Yacc、BYACC/J、MKS Yacc、Abraxas pcyaccがある。いずれの派生版も改良されてはいるが基本的な部分は変わらない。むしろ現在yaccコマンドはbisonコマンドがラップし、-y オプションを付けることでPOSIX Yaccモードに縮小した機能で動くようになっている。
C言語以外への対応として、YaccはJava、Ratfor、EFL、ML、Ada、Limboなどの言語を生成する版へも移植されている。
このうちJava向けには、Yaccと同様のLALR方式のjacc、CUP (JavaCUP)、SableCC、
jay、またYaccと異なる方式では、LL(k)方式のJavaCCとCoco/R、そしてLL(*)方式のANTLRがある
。Bisonのラッパで、アクション部をJava言語で書けてJavaクラスによる構文解析器プログラムを生成できるJBisonというものもある。
オリジナルのYaccはOpenSolarisの一部として更新されており、オープンソース化されている。ソースコードはPlan 9やOpenSolarisの標準的なディストリビューションに含まれる。
オリジナルYacc以降の改良点としては、関数名や変数名のカスタマイズ、パーザの状態をグローバル変数ではなくスタック上に記録するリエントラント化、C++への対応等、アプリケーションからのパーザ利用を便利にするものが多い。一方、BtYaccはパーザアルゴリズムにバックトラッキングを導入して文脈依存文法をサポートすることにより構文木の曖昧性を解消することを目的とした派生である。
Yacc 基本構成
ユーザは変換仕様をYacc文法ファイルとしてのテキストファイルを作っておく。
yaccコマンド
は、fileName で与えたYacc文法ファイル（たとえば"wiki_samp1.y"）（伝統的に拡張子は.yがつけられることが多かった）から構文規則を入力し、それに基づくLALR構文解析器になるC言語のソースプログラム（通常"y.tab.c"）を出力する。-rオプションでコード部分だけ"y.code.c"ファイルに独立させることもできる。
このC言語ソースプログラムにはLALR解析テーブルおよびドライバルーチンが含まれる。
特に、構文解析全体を行う関数にはyyparse()という名前がついている。よってこのプログラムにあらかじめ適宜yyparse()を呼び出すmain()関数を加えておくなどして（それはYacc文法ファイル中の「追加Ｃプログラム部」での記述でも可能）、ほしい変換プログラムを完成することができる。
-dオプションで生成するヘッダファイル"y.tab.h"は、Lexがトークン処理を行うときに、Yaccが割り当てたトークン値（256～）を正しく使うよう、Lex実行時に与える。
Yacc 基本構成
-vオプションにより、生成パーサの文法、終端記号、非終端記号、状態の種類とそれぞれの判定パターンおよびそのシフト、還元等の措置や状態遷移先といった解析テーブル情報が、人に分かりやすい形でテキストファイル"y.output"に出力される。（この"y.output"リストの見方が分かりにくい。ピリオド「.」（Yaccの種類によっては下線「_」）は現在のカーソル位置であることなどは知らないと分からないであろう。説明は日本語文書では良書「Cコンパイラ設計(yacc・lexの応用)
」のほかに見つけにくいが、英語ではいくつかある




）
-tオプションを指定すると、生成パーサが実行されるときに、状態番号、スタック状態、読んだトークン、意味値の演算の様子、変化した状態番号などが、逐一標準エラー出力に表示されるのでデバッグに役立つ（コンパイルオプションも関連）。
次に、Yaccで生成し構文解析器ソースプログラム（"y.tab.c"）をccコマンドやgccコマンドなどでコンパイルする。このとき、Lexも利用したのであればその出力（"lex.yy.c"）も並べて指定する。これらに対応するライブラリもコンパイルオプションによってリンクさせる。
Yacc 基本構成
コンパイルで作成された変換プログラムを実行すると、標準入力（FILEポインタyyinで変更可能）（yywrap関数で複数ファイルの連結が可能）から変換するファイルを読み込む。これを字句解析器関数yylex()によってトークンにして構文解析が実行される。変換結果やエラーは、Yaccのアクション部や呼ばれる関数で書いた処理によりそれぞれ出力される。syntaxエラーなどは通常標準エラー出力に出るが、形式や出力先をエラー報告関数yyerror()でカスタマイズできる。Yaccのオリジナルなエラーメッセージでは情報が貧弱である。開発・運用で頭を抱えないようにするためには、特に発生場所のファイル名、行番号およびトークン番号などをエラーメッセージに追加するようにyyerror()を作っておくことが望ましい。
Yacc文法ファイルwiki_samp1.y（後述）から構文解析実行プログラムwiki1.exeを実行するまでの実際のコマンド例（Windows Cygwin環境）を示す。
GNUコマンドプログラムbison はYacc上位互換であって、オプション -y によりYacc互換の処理をしてくれる。
解析させるファイルindata.txtの中には、たとえばテスト用の文字列「10+20*30-40《改行》」を入れておく。もちろん「 < indata.txt」を除いて対話的に手入力してもよい。
Yacc 基本構成
Yaccの構成は以下のようになっている。
以下に、Wikipedia用に作成した動作確認済サンプルプログラムを示し、その動作を逐次説明していく。
いま作ろうとする電卓は、内部的に64ビット浮動小数点で動作し、整数と演算子、カッコなどからなる式を与えて改行すると計算結果を答えるという会話を繰り返すものである。
目的とする出力例
小数はサポートしないが、「314/100」のように整数の除算で小数にあたる数を与えることはできる。
「+」、「-」、「*」、「/」、べき乗の「**」、剰余の「%」。
「+」および「-」においては単項と二項の両方。
カッコ「()」で演算順序を明示すること。
課題プログラムのYacc構文定義は以下のように作ることができる。これをたとえば、ファイル "wiki_sample.y" に入れ、Lex出力ソースに代えて後述の「後半」内容をつないで作成し、上記#コマンド例のように実行すればよい。
マクロ定義や文法規則のアクション関数をC言語で記述できるパートである。構文解析器プログラム先頭にそのままコピーされる。
例:
Yacc 基本構成
開始記号（"%start"）、値型の集合（"%union"）、トークン（終端記号）宣言（"%token"）、グループ（非終端記号）宣言（"%type"）、 演算子優先順位指定（"%left", "%right", "%nonassoc"）などを、必要に応じて記述できるパートである。 
例:
Bisonの場合はBison宣言部と呼ぶ。この場合さらに、衝突警告抑制（"%expect"）、純粋（再入可能）構文解析器指定（"%pure_parser"）ができる。
文法規則部には1個以上のYacc文法規則
を記述しなければならない。
ここで，変換結果とは、規則が記述する非終端記号。
構成要素とは、この規則がマッチするかを判定するために文法どおりの順に並べられる、0個以上の終端記号や非終端記号の列。
例:
同じ変換結果を生む複数の規則は次のように簡略に連続記述できる。
「;」は省略可能。
見て分かるとおり、構文規則は読み書きしやすいBNF記法になっている。
Yacc 基本構成
規則にマッチするたびに行ないたい動作、たとえば変換結果の意味値（"$$"）をその構成要素の意味値（"$1", "$2", …）から計算すること、あるいは値を表示出力などは、C言語命令によるアクションとして「{ }」に囲って、マッチ直前に実行したい構成要素の直前に付して、あるいは規則適用時実行でよければその規則の最後の構成要素のあとに記述する。
規則は再帰的に定義できる。例で
の規則6は、「NUMと名付けた数値トークンがきたら、それ1個単独でも式exprになる」と宣言している。
そして規則9は「expr '+' exprという並びもexprである」という意味で自分expを記述しているから、再帰的な定義である。すると、規則は繰り返して適用できるから、
など1個以上のNUMの加算式が、わずか2個の規則だけで表現できる。構文解析器実行時にこのうちのどれがやってきてもexprにマッチすると認識できることになる。
トークン値は実際にはASCIIコードと重ならない256以上の整数であるが、Yacc文法記述者はその値を知らなくてよく、NUM, EOLといった通常大文字で記述する記号で宣言と規則で統一的に記載すればよい。
Yacc 基本構成
トークンの意味値が伴う種類のトークンは、とりうる型は"%union"によって列挙して定義しておく。そして"%token"で"<ldval>"のように共用体のどのメンバーであるかを明示できる。アクション中で"$$"と書かれた意味値はC言語になったとき"lval.ldval"のように共用体中の要素を指すように自動変換される。このように意味値が伝わっていく。
関数、変数等をC言語で記述できるパートである。構文解析器プログラムでyyparse()関数の展開が終わったあとの末尾に、そのままコピーされる。
たとえば字句解析器関数yylex()、エラー報告関数yyerror()、C言語メインプログラムmain()なども、それぞれ必要があればここに記述する。
Yaccが生成する構文解析器は、内部にスタックをもっている有限状態機械である。次のトークンを1個読み（先読みトークン;look-ahead token）変数yycharに入れるが、すぐにスタックにシフトするわけではない。構文解析器はその前に、マッチする規則があるかどうか、構文解析器の現在の状態番号（0,1,…）（これは常にスタックの最新＝右端のものである）のもとでYaccが生成しておいた解析テーブルを検索して調べる。スタックの右端と各規則を合わせてみて解析する（右端導出）。
構文解析器は終了条件まで以下を繰り返す処理である：
Yacc 基本構成
現在の状態で先読み（lookahead）トークンが必要で現在それがセットされていなければ、yylex()を呼んで先読みトークンをもらう。
そして現在の状態と先読みトークンによって決まるアクションを実行する。
Yaccにより解析テーブルに展開されるこの機械のアクションの種類は、
シフト（shift）先読みトークンが必要で、それをスタックに（右から新しいものを押し込むイメージで）1個追加（プッシュ）する。先読みトークンは消費される。
還元（reduce）n番めの規則の右辺にある記号群から左辺のグループ（非終端記号）への置き換えを適用して、右辺に対応した数のスタック要素をポップアップ（右に出して消すイメージ）する。スタックのサイズは縮む（まさにreduceする）。そして、左辺であるグループ（非終端記号）を1個プッシュしなおす。このグループに意味値があれば、戻り値からセットされる（電卓の例でいえば中間計算結果）。同時に、状態は（現在の状態ではなく）スタックのトップ（最も右）にある状態番号にされる。いわばサブルーチンに行って帰って来たような状態である。還元を起動する条件として、解析テーブルに「.」（バージョンによっては「$default」）と書いてあれば無条件に実行されるが、「MINUS」などと先読みトークン値が与えられているときはそれが一致したときに限って実行される。
Yacc 基本構成
遷移（goto）生成した非終端記号をshiftする。次の終端記号はこのあとのshiftに任される。先読みトークンは消費されない。
受理（accept）構文解析の正常終了であり、yyparse()から戻り値0で正常復帰する。この動作はyylex()から0か負が返って次の終端記号が終わりを意味する$endになったとき、規則0「$accept: 全体の非終端記号名 $end」によりスタックが正しく$acceptの1個に還元できたときに行われる。
エラー（error）解析表の空欄、すなわち次に現れてはならない終端記号があったときマッチされるべく展開される。すなわち、構文解析器はエラーを検出すると、「error」トークンが正常に合致する規則が見つかるまでスタックをポップアップしながら戻っていく（最後までみつからなければyyparse()から1で異常復帰する）。見つかるとそこに「error」というトークンがあったとみなして、検出される規則のアクションを実行する。そして、先読みトークンはエラーを起こしたトークンに進める（リセット）。Yaccはエラー多発防止のため、トークン3個の読込みおよびシフトが成功するまではこのエラー状態にとどまるが、ユーザがアクションでyyerrok（エラー回復）マクロを実行すればその途中でも正常状態に戻る。
Yacc 基本構成
である


。
可能な還元はそのままいくつか行ったあとはじめて、トークンはシフトされる。
構文解析器は、入力されたトークン列をスタックに入れては次々に上記のように規則適用を試みて、成功するたびに還元していく。そしてテーブルの指定によって状態遷移していく。
入れ子の下位の非終端項目（グループ）が確定すれば、その値がその非終端項目に該当する上位の未確定な右辺の項に代入されて、その左辺のグループがスタックにプッシュされることで、だんだん上位に向かって解決されていく。
トークンを受けた状態番号を状態スタックに出し入れすると完全同期して、（あれば）そのトークンの意味値も意味値スタックに出し入れする。これにより、アクションによる意味値の計算を保証している。
最終目標は、全部読みきったときに、"%start"で指定され解析をスタートした非終端記号（デフォルトは最初に書かれている規則の左辺）が、変換の結果$accept 1個に還元できたかどうか調べることである。
もしそれが（エラー発生がerrorトークンで解決できなかったか、YYABORTマクロを実行されたなどの原因で）できなかったのなら、入力文字列はこの文法に適合しないエラーということが分かる（入力文字列が正しければYacc文法ファイルが間違いということもある）。
Yacc 基本構成
もしできたなら、この文法に適合したと判断でき，それに直接あるいは再帰的に入れ子で含まれる全部の要素に該当する入力トークン列が確定する。電卓の計算結果やコンパイラのための抽象構文木といった応用のための）意味値ができていれば、それもアクションで、都度あるいは最後に、表示したりファイルに書き出すことができる。
たとえば、この構文規則から生成した構文解析器が、数値トークンNUM、End Of LineトークンEOLおよび演算子からなるトークン列
を読むとしよう。
Yacc 基本構成
ただこの前半では、トークンNUMが何の文字列をもってそう認識するかは定義されていない。Yaccにユーザが与えたYacc文法ファイルには、通常、字句解析をするための文法が存在していないからである（もっとも、無理に字句解析までやらせることは、複雜になるが不可能ではない）。
その代わりトークンの入力は、yylex()という決まった名前の関数を呼ぶように展開される。目的の構文解析器の実行時に、Yaccによって生成されている構文解析器関数yyparse()は、ひとつひとつトークンをyylex()を呼んで要求する。yylex()はどこからか文字列を呼んでひとつトークンを返し，あれば変数lval経由でその意味値も同時に返し、ファイルの終端に達したとき（1行ごとにyyparser()から帰ってはまた呼び出す構文解析器を作るにおいては、行末に達したなどそのプログラムが解析のまとまりと認識している区切りに達したとき）はバイナリ0か負数を返して知らせる。
利用者はyylex()を自分でプログラミングするか、Lex、Flexなどの字句解析ツールを使って作成する必要がある。つまりLex、FLex、JFLexなどの字句解析器ジェネレータは、Yaccが作ってくれない関数yylex()を自動で作ってくれるツールといえる。
実際にはこの課題プログラムに
Yacc 基本構成
を与えたとして値も追跡したい。この場合「後半」のyylex()プログラムは構文解析器実行時に、次のトークン群、およびあれば以下でカッコ《》内に付記している意味値を、要求するたびに1個ずつ構文解析器関数yyparser()に返してくるはずである。
最初に、スタックが空
の状態で内部にもつ状態番号を0にして%startで示されているdialogueが調べられる。適用できる規則は右辺が空の規則1なのでこれが適用される。状態スタックにはその0がはいる。このスタック状態を次のように図示できる。
そして状態番号は1に行く。yylex()の中で初回だけ、
と出し、prompt()というユーザ定義関数によって、
と表示する。電卓ユーザまたはファイルから、
が入力されると、yylex()関数はトークン1個ずつyyparser()に返していく。
まずNUM《10》が読まれ，状態1での適用規則が探される。還元できる規則とはスタック右端がマッチしないので、ありえる記号としてそのテーブルに登録されている「NUM」に対する操作が行われる。すなわち、スタックにはじめてそれが1個シフトで入れられ状態5になる．
規則6
（単独のNUMはexpr）だけがマッチするからこれが適用され、
に還元されてスタック内容が入れ替わる。
Yacc 基本構成
（この規則6にアクションは書いてなかったが、戻り値がないのではなく、Yaccの空でない規則に対するデフォルトアクション
{{{1}}}}
が実行されて10がこのexprの値に代入されたのである。）
そしてテーブルに書かれていた状態番号10になる。
ここで'+'を読んでシフトし、状態16になってNUM《20》までシフトしたとき、
となるから、先と同様に規則6でNUMがexprに還元され
となる（以下、内部状態番号の変化は省略するが次々と遷移していく）。
ここで現在スタックの右端にある3トークン「expr '+' expr」が規則9（加算式）にマッチして還元が起こりそうに思えるかもしれないが、起こらない。先読みしている次のトークンが現在の「+」よりも優先順位が高い「*」なので還元はせず、シフトを行う（もし演算子優先順位を同列にしていたら還元が起こって先に加算をするであろう）。
NUM《30》を読んでシフトし
規則6で還元し、
ここで、右端の3トークンが
にマッチしていて、次のトークンは'-'であり、今度は遠慮なく還元が実行されてスタックから3個消えて、意味値が600と計算された左辺のグループexprが押し込まれるので、
のように2個分縮むことになる。
次に先読みしていた「-」を読み直す。ここの状態で右端の3トークンが
Yacc 基本構成
にマッチしていて、次のトークンは'-'であり、これも還元が実行されてスタックから3個消えて、意味値が10+600=610と計算されたグループexprが押し込まれるので、
のようにまた2個分縮む。
（このように、還元が起こるたびに、まるでゲームのテトリスで同じ色のブロックが並んだときのように、スタックが伸びてはストンストンと短くなる。還元が長く起こらないとスタックが長くなって、既定のサイズを超えるとスタックオーバフロー例外で異常終了してしまうのも、ゲームオーバーに似ている。なお、スタックオーバフローを起こさないためには、
explist ',' exp
のような右再帰の形を避けて
exp ',' explist
のような左再帰の形で定義することである。規模が大きくなる場合はスタックサイズの定義マクロYYMAXDEPTHの値を大きく指定する．）
またまた先読みしていた「-」を読み直す。今度はさすがに適用できる規則がなくシフトされる。
次にNUM《40》が読まれてもシフトするしかない。
この状態で先読みトークンに、電卓ユーザが押した改行EOLがくる。
この状態において、演算子優先度が関係ない先読みEOLに遠慮する必要がないので、
がマッチとして還元が実行されて、スタックから3個消える。その代わり、意味値が610-40=570と計算されたグループexprが押し込まれるので、
Yacc 基本構成
のようにまた2個分縮む。
先読みしていたEOLを読み直す。すると、この状態でexprには、
しかマッチせず、アクションのprintf関数が実行されて，
という計算結果と次のプロンプトが標準出力に見事に出てくる。スタックは、
になった。
またまたEOLを読んで今度はシフトする。
これはdialogueの再帰的な規則のひとつ
の3個のトークンとマッチするので、還元が実行されてスタックから3個消えて左辺のグループdialogueが押し込まれ、
だけになる。
このあと入力ファイルにまだ演算させたい式を書いた行が書かれていれば、上と同様に計算され結果が表示されるであろう。が、いまの場合はファイル終端になってyylex()が
Bye.
と表示して0を返す。すると内部的には$endという特殊トークンがシフトされ
となるが、これが暗黙に定義されている規則0
とマッチするので、パーサは$accept（受理）を得て目的を成功裏に果たしたということでスタックをすべてクリーンアップして，yyparse()呼出元に制御を返す。
このようにYaccの作るパーサは、解析した文字列が最後に%startの記号（デフォルトは最初に書いた規則の左辺）に見事にマッチし文法に合格したと判断されたとき正常に戻り値0でyyparser呼出元に帰る。また、YYACCEPTマクロを実行すれば即正常で帰る。
Yacc 基本構成
構文解析エラーが起これば異常（戻り値1）でyyparser呼出元に帰る。また、YYABORTマクロを実行すれば即異常（戻り値1）で帰る。
途中、意味値をユーザ定義のアクションや関数で出力すれば、計算の目的が果たせたことになる。
上記 wiki_sample.y 前半に引き続き後半として記述すべき追加Ｃプログラム例は、以下のとおりである（ここではユーザがyylex()関数を手で書いているが、同じ機能のプログラムは、FLexに字句規則を与えて自動生成させた方がスマートであろう）。
上の例では電卓のようにその場で値を求めることはできる。しかしYaccを利用してコンパイラを開発する場合は、このあとのコード生成部(2)に渡す抽象構文木（abstract syntax tree、AST）というデータの構造を構築していかなければならない。たとえばアクションでユーザ定義関数を呼び出し、
のように左辺と右辺を「+」で結合してそのポインタを返すような操作を行わせることで可能である。すると、構文解析が末端から順次還元を行って根まで統合されて停止したとき、同じ構造の抽象構文木が根まで完成して得られることになる。
このように葉から順に根に至る構文解析法をボトムアップ構文解析という（ここでは木を上下逆さまにして根は一点にしたイメージなので“ボトムアップ”という）。
Yacc 基本構成
この方式では、次の有名な例のように、同じ入力を同じ構文規則で複数の解釈ができてしまう曖昧性が避けられない。
Yaccではyaccコマンド実行時に解釈が複数生じる曖昧なケースを発見した場合に「還元／還元衝突警告」または「シフト／還元衝突警告」を出す。これによって、文法を作成中なら文法を、そうでなければ構文規則を改良するきっかけが得られる。
まず「還元／還元衝突警告」が出た場合であるが、パーサが正しい処理をできない構文要素が生じてしまうので、文法、または構文規則のYacc定義を直した方がよい。
ある非終端記号から別の非終端記号に至る呼び出しパスが複数あれば、それは間違いなので直す。
しかし元の言語が複雜すぎてうまく直せない場合は、片方を実体は同じでも別の名前を付けるトークン由来で構成するようにし、Lex側がどちらのトークンをYaccパーサに出すかは状態に応じて変えるようにコーディングしておく方法がある：
Yacc 基本構成
状態がトークン列だけから一意に決められるならLex単独で処理できる。しかし、Yaccが実行時にあるルールのマッチを検出したときにはじめて状態を変えたいという複雜なケースでは、次のようにする。LexとYaccで共通の状態変数を設けておき、Yaccの{ }内に記述するアクションで、区別したい何かのフェーズなどの状態に応じて状態変数値を変えてやる。そうすればLexの生成したレキシカルアナライザは、実行時にまさに読んでいる入力トークン列による状態変数値に応じて、ある入側トークンを別々のトークンに動的に変換し分けてYaccの生成したパーサに渡す、という方法である。非常にダイナミックな技である。
次に「シフト／還元衝突」であるが、このときYaccは標準で、（特に演算子優先規則で指定されていないかぎり）シフトを選ぶようにできている。たとえば上記の例ではexpr2不成立のときにstmt2を実行するようにパーサのテーブルが作られる。このように距離の近い記号の関係を優先するよう動作するのは、多くのプログラミング言語のコンパイラに向いているといわれているが、後述のように注意が必要である。
構文上期待外のトークンがくるとアクションが見つからないので、パーサは、状態を戻して、errorという特定トークンのアクションがその状態に定義されているかどうか調べ、あれば実行する。最大3回まで戻しても見つからないときには入力テキストが途中でもそこでパースを打ち切ってしまう。これを利用してたとえば命令リストにerrorトークンのみの右辺をOR（|）結合しておけば、ある命令に属するオペランドに期待外トークンがあっても、そこで警告を出して次の命令以降のパースを続行してくれる、使いやすいコンパイラを作ることができる。ただ最大3回固定なので、深さの差3以内の上位にerrorを処理する構文を書いておかなければ利用できない。またはy.tab.cファイルの変数yyerrstatusの初期値を10などと増やしてやる必要がある。
Yacc実行時に報告されるシフト／還元衝突は、シフトが選ばれるだけで十分と確信できるケース以外は、実は本来0件にしておくべきである。なぜならパーサ実行時にシフトが選ばれて動作することにより、入力されたトークン列によっては行き止まりになる。すなわち期待外のトークンとされ、上記のエラー処理に飛んでしまうからである。Yaccは衝突に対応する枝分かれをすべてバックトラックでたどって解空間を全探索するようにはできていないのである。このため、衝突を残しておくとパーサを当然通ると思った入力が通らず苦労することになる。
Yacc実行時になんらかの衝突が報告されるとき、および、上記パーサ実行時に正しいはずの入力がsyntax errorとなるときの主な対処方法には、次のようなものがある。
パーサ実行時の期待外トークンで、あるトークンが複数の場面でどう絡んでいるかを調べるには、y.outputファイルでその状態番号を見つけて熟読し、その状態番号へ飛んでくる状態を1, 2段階さかのぼってたどってみると見えてくるものである。y.outputにはまた、状態番号に対して衝突種類、トークンに対して実行されないアクションを囲むカッコ「[ ]」が出力されているので、場所や影響が分かる。
入力言語があまりに複雜な場合、またはプリプロセッサ命令を含んでいる場合、パースを2段階の直列構成にするという大胆な解決策もある。すなわち、1段階めの前処理Yaccパーサは曖昧性を解決するだけのための簡単な文法で動く。その出力の曖昧性を解決したトークン列を2段階めの本処理Yaccパーサに渡す。3段以上にすることが有効な場合もあろう。文法の性格によっては、この構成にすることで、むしろそれぞれをすっきりさせることができる（エラー位置の表示処理は複雜になる）。
八里区
八里区（バーリー/はちり-く）は台湾新北市の市轄区。
八里区 地理
八里区は台北盆地の西北端、淡水河の河口西岸に位置している。東北は淡水河を隔てて淡水区と、西は林口区と、南は観音山を隔てて五股区とそれぞれ接し、西北は台湾海峡を臨む。地形の約2/3は丘陵地であり、その他は平坦な沿海部に分類できる。
八里区 歴史
明代の1605年、スペイン人が淡水河を遡上して台北盆地に到着した際、武澇湾番社の3大部落（現在の新竹、宜蘭一帯）を降伏させ支配下に置いた。その中の地名に「Parecuchu」とあり、それが「八里」に転訛したとされる。また別説では1358年頃に八里地区で活動していた原住民の「Arieun」が転訛したものとも伝えられる。2010年12月25日には台北県が新北市に改編されたことに伴い八里区と改編され現在に至っている。
八里区 歴代区長
http://tour.tpc.gov.tw/
エブロネス族
エブロネス族（拉：Eburones (エブロネース)、ガリア語：希文字で Ἐβουρωνοί およびローマ文字で EBVRONOI、Ebourōnoí (エブローノイ)、仏：Éburons (エブロン)、蘭・独：Eburonen (エブロネン)）は、古代ガリア北東部のベルギウム（現在のベルギー）に居住していたゲルマン人出身の部族。ガリア人の一派であるベルガエ人にも数えられる。
彼らの領土は、現在のベルギーのリエージュ州とリンブルフ地域（※二つのベルギーのとオランダのに同名州）および、ドイツのアーヘンまで近隣地域に約対応していました。
エブロネス族 歴史
カエサル著『ガリア戦記』によれば、彼らはマース川とライン川の間に居住していた。主邑はアトゥアトゥカ（Atuatuca）であったとされている。
紀元前54年、ガリア戦争の最中に、アンビオリクスが族長となった。それまで結束することのなかったガリアをアンビオリクスはまとめあげ、共和政ローマの属州総督ガイウス・ユリウス・カエサルに対して攻撃を開始した。
アンビオリクスは、ローマ軍の冬営地を急襲し、1個軍団を壊滅させ、総督の副官であるクィントゥス・ティトゥリウス・サビヌスとルキウス・アウルンクレイウス・コッタを敗死させた。
しかし、ローマ軍総司令官カエサルが軍をまとめて反撃を始めると、アンビオリクスは敗北した。エブロネス族は報復のために徹底的に根絶され、彼らの土地にはトゥングリ族が移住させられた。
平渓区
平渓区（ピンシー/へいけい-く）は台湾新北市の市轄区。
平渓区 地理
平渓区は新北市東北部、基隆河上流に位置し、東は瑞芳区、双渓区と、南は坪林区と、北は基隆市、汐止区と、西は石碇区とそれぞれ接している。平原が極めて乏しく、四面を山に囲まれた地形をなしている。
平渓区 歴史
清代の乾隆ごろに漢民族の入植が開始され、「石碇堡」と呼ばれるようになった。
日本統治時代の1901年（明治34年）11月11日、基隆庁の管轄となる。
1905年（明治38年）7月1日、台湾総督府により「十分寮区」と「石底区」の2つの地区が設置された。
1909年（明治42年）10月25日、基隆庁が台北庁に合併し、十分寮区と石底区は台北庁水返脚支庁の管轄となる。
1920年（大正9年）10月1日、地方改制の際に十分寮区と石底区が合併して台北州基隆郡「平渓庄」となった。
第二次世界大戦後の1946年1月16日、中華民国統治下で「平渓郷」へ改編された。
2010年12月25日、台北県が新北市に改編されたことに伴い平渓区へ改編された。
万里区
万里区（ワンリー/ばんり-く）は台湾新北市に位置する市轄区。
万里区 歴史
万里区は伝承では鄭成功がオランダ人を駆逐した後、福建から洪水閣と称す者がこの地に入植し、漁業を始めたことが集落の開始とされている。清代になり1684年には諸羅県に帰属し、その後淡水庁淡水堡、芝蘭堡、基隆庁金包里堡と行政改編が続いた。
日本統治時代の1901年（明治34年）11月11日、基隆庁の管轄となる。
1905年（明治38年）7月1日、台湾総督府により「瑪鋉区」地区が設置された。
1909年（明治42年）10月25日、基隆庁が台北庁に合併され、瑪鋉区は台北庁金包里支庁の管轄となる。
1920年（大正9年）10月1日、地方改制の際に瑪鋉区と金包里区の一部が合併して台北州基隆郡「万里庄」となった。
第二次世界大戦後の1946年1月16日、中華民国統治下で「万里郷」へ改編された。
2010年12月25日、台北県が新北市に改編されたことに伴い金山区へ改編された。
万里区 交通
鉄路でのアクセスは万里区に無いが、基隆駅からバスにて約40分でアクセスが可能である。
烏来区
烏来区（ウライ/うらい-く）は台湾新北市の市轄区。
烏来区 名称
地名はタイヤル語の「ulay」（温泉）に由来する。区内には烏来温泉が湧出しており、台北市中心部から1時間余りで行ける、近郊の観光地として発展している。清代には烏萊社あるいは汚萊社、もしくは「ulay」を漢訳して湯社とも記された。日本時代には初期をのぞいてはカタカナでウライと表記されたが、太平洋戦争中の1943年、山地名の日本色強化政策により、再び烏來社と漢字表記に戻された。
烏来区 地理
烏来郷は新北市の最南端、雪山山脈と加里山山脈の間に位置している。東北は洪爐地山、ロホン山、大桶山が広がり坪林区、石碇区と接している。北側には大桶山、四寮山が広がり新店区と接し、西北はカボ山、ロペイ山、北挿天山を挟んで三峡区と、西南は北挿天山、ルペー山、ララ山、タマン山、バボークル山を挟み桃園市復興区と、東南は雪山山脈の主要山系であるバボークル山、棲蘭山、拳頭母山、阿玉山、洪爐地山を挟み宜蘭県礁渓郷、員山郷、三星郷及び大同郷と接している。面積321.1306平方Kmは新北市全体の15.6%を占め、新北市最大の市轄区である。
烏来区 歴史
清代中期、タイヤル族の人々がこの地にやってきて定住していた。民族学的にはスコレック群(swqoleq)メリパ系統(Malepa)と考えられている。伝説に依れば、その祖先は南投県仁愛郷のピンスブカン(Pinsebukan、岩の割れた所の義)に住居していたが、人口増加により一部が北に移動し、道光年間に札亜孔社の亜維家族が現在の烏来里、忠治里一帯に移転している。
1895年、日本による統治が開始されると、烏来は台北県の管轄となった。1896年、大嵙崁撫墾署が設置され、台北県の他に基隆、淡水庁の理蕃事業を担当するようになる。1898年、撫墾署が廃止となり、烏来は台北県景尾弁務署の管轄に置かれると共に、隘勇線が設置されたが、1910年、南接するガオガン蕃の帰順により警備は撤廃された。1901年、行政改編を受け深坑庁の管轄となり、更に台北庁新店支庁の管轄となり、1920年には台北州文山郡の管轄となり、「蕃地」としてその下に龜山、大粗坑（新店）、平廣坑、乾溝、火燒樟、ウライ、阿玉、ラハウ、トンロク、リモガン、チャコン、カラモチ、シラック、タラナン、金瓜寮、姑婆寮、磨璧潭、大粗坑（坪林尾）、紅山水、桶後溪の二十字（あざ）が設けられた。
烏来区 歴史
1946年、中国国民党による台湾統治が開始されると、烏来地区で地方自治が実施され、この地に烏来郷が設置され、文山区の管轄下に置かれた。1946年6月15日、烏来公所が成立し、その下に烏来、信賢、忠治、孝義、福山の5村が設置された。1949年3月1日、北峰区署管轄に変更となり、1950年8月に区署が廃止されたことで台北県直轄と変更された。2010年12月25日には台北県が新北市に改編されたことに伴い烏来区に改編され、現在に至っている。
地域別の川の一覧
地域別の川の一覧（ちいきべつのかわのいちらん）では、地球上の主要な川を大陸ないし大州の地域別に羅列する。
本項の掲載基準は下記のいずれかを満たすものとする。
河川が途中で名称を変える場合や、本川として扱われない支流を記載する場合は「-」で区切って記載する。
地域別の川の一覧 一覧
ミシシッピ川（アメリカ合衆国／メキシコ湾）†1,2,4
ミズーリ川（アメリカ合衆国／ミシシッピ川） - レッドロック川（アメリカ合衆国）†1,2
アーカンザス川〔アーカンソー川〕（アメリカ合衆国／ミシシッピ川）†1,2
オハイオ川（アメリカ合衆国／ミシシッピ川） - アレゲニー川（アメリカ合衆国）†2
レッド川 (ミシシッピ川水系)（アメリカ合衆国／ミシシッピ川）†2
アマゾン川（ペルー、ブラジル／大西洋）†1,2,3,4
マデイラ川（ボリビア、ブラジル／アマゾン川） - マモレ川（ボリビア、ブラジル） - グアポレ川（ブラジル、ボリビア）†1,2,4
ウカヤリ川（ペルー／アマゾン川） - アプリマック川（ペルー）†2
ジュルア川（ペルー、ブラジル／アマゾン川）†2,4
プルス川（ペルー、ブラジル／アマゾン川）†2
ジャプラ川〔カケタ川〕（コロンビア、ブラジル／アマゾン川）†2
ネグロ川〔グアイニア川〕（コロンビア、ベネズエラ、ブラジル／アマゾン川）†2
シングー川（ブラジル／アマゾン川）†2
双渓区
双渓区（シュアンシー/そうけい-く）は台湾新北市の市轄区。
双渓区 歴史
日本統治時代の1901年（明治34年）11月11日、基隆庁の管轄となる。
1905年（明治38年）7月1日、台湾総督府により「頂双渓区」と「大平区」が設置された。
1909年（明治42年）10月25日、基隆庁が台北庁に合併し、頂双渓区と大平区は台北庁頂双渓支庁の管轄となる。
1920年（大正9年）10月1日、地方改制の際に頂双渓区、大平区と槓仔寮区の一部が合併して台北州基隆郡「双渓庄」となった。
第二次世界大戦後の1946年1月16日、中華民国統治下で「双渓郷」へ改編された。
2010年12月25日、台北県が新北市に改編されたことに伴い双渓区へ改編された。
貢寮区
貢寮区（ゴンリアオ/こうりょう-く）は台湾新北市の市轄区。台湾電力による龍門原子力発電所、いわゆる「第4原発」が建設されていることで知られる。
貢寮区 歴史
古くからこの地域に住むバサイ族は、自分たちの生活領域を「Kivanowan」（基瓦諾灣）と呼んでいた。また、スペイン人がこの地を「Santiago」と命名したことから、「三貂社」という名前も使われるようになった。18世紀後半以降に漢民族の入植が開始され「摃仔寮」と呼ばれるようになった。「摃仔（Kòng-á）」は平埔族の一部族であるケタガラン族の言葉で、「獣を捕らえるための罠」を指す「Kona」の音写である。
日本統治時代の1901年（明治34年）11月11日、基隆庁の管轄となる。
1905年（明治38年）7月1日、台湾総督府により「槓仔寮区」と「澳底区」が設置された。
1909年（明治42年）10月25日、基隆庁が台北庁に合併し、槓仔寮区と澳底区は台北庁頂双渓支庁の管轄となる。
1920年（大正9年）10月1日、地方改制の際に槓仔寮区と澳底区が合併して台北州基隆郡「貢寮庄」となった。
第二次世界大戦後の1946年1月16日、中華民国統治下で「貢寮郷」へ改編された。
2010年12月25日、台北県が新北市に改編されたことに伴い貢寮区へ改編された。
るろうに剣心 -明治剣客浪漫譚-の登場人物一覧
るろうに剣心 -明治剣客浪漫譚-の登場人物一覧（るろうにけんしん めいじけんかくろまんたん のとうじょうじんぶつのいちらん）は、和月伸宏の漫画『るろうに剣心 -明治剣客浪漫譚-』およびそれを原作としたアニメ、ゲーム作品に登場する架空の人物の一覧である。
なお、緋村剣心、相楽左之助、四乃森蒼紫、鵜堂刃衛、志々雄真実およびその一派、雪代縁は各キャラクターの個別記事を参照。
るろうに剣心 -明治剣客浪漫譚-の登場人物一覧 主要人物
緋村剣心（ひむら けんしん）
声 - 涼風真世（幼少時 - 鈴木真仁） / 斉藤壮馬（幼少時 - 田村睦心） / 緒方恵美（CDブック版）
演 映 - 佐藤健（幼少時 - 福崎那由他） / 宝 - 早霧せいな / 永久輝せあ / 松 - 早霧せいな / 京 - 小池徹平
本作品の主人公。穏やかな風貌の優男だが、幕末期は「人斬り抜刀斎」として恐れられた伝説の剣客。初登場時28歳。
→詳細は「緋村剣心」を参照
神谷薫（かみや かおる）
声 - 藤谷美紀 / 高橋李依 / 桜井智（CDブック版）
演 映 - 武井咲、宝 - 咲妃みゆ / 彩みちる、松 - 上白石萌歌、京 - 井頭愛海
身長155cm、体重41kg。1862年（文久2年）10月10日生まれ。千葉県出身。血液型O、蟹座。初登場時17歳（満15歳）。
本作品のヒロイン。一人称は「私」。神谷活心流道場師範代（物語終盤で師範となる）で、その美しい容姿と剣の腕から東京では「剣術小町」と呼ばれる。活発で正義感の強い性格だが、それゆえに激昂しやすい面もある。命をかけた修羅場を経験し、剣術の腕前も確かであるが、繕い物を除く家事は苦手。特に料理は本人としては得意なつもりなのだが、周りからの評判はすこぶる悪い。また、酒癖が非常に悪く、酔うと剣心らも手が付けられないほど凶暴になる。
るろうに剣心 -明治剣客浪漫譚-の登場人物一覧 主要人物
家族は父・越路郎、剣術家で水墨画家の祖父がいたことが明言されているが、ともに故人であり、母親に関しても原作劇中で一切触れられていない（アニメ第1作では故人という設定）。食費などの費用の出所は不明だが、祖父の残した水墨画を売って生計を立てたこともある。アニメ第1作の第24話では出稽古で生計を立てていると発言している。
神谷道場の土地を奪われそうになった事件で剣心と出会い、以後彼との絆を深める。流浪人に戻る決意をした剣心が、唯一別れを告げた相手。序盤は剣心がいつか流浪人に戻ることを恐れていた。
剣心が「闘いの人生を完遂する」と決意した姿を目にして、彼のことをずっと側で支えていたいと思うようになる。最終的には剣心と結婚し、息子・剣路を儲けている。
『明日郎 前科アリ（異聞）』では神谷道場にやって来た明日郎と阿爛を剣路と共に迎え入れている。なお、料理の腕はおにぎりを美味く作れるほどには上達している。
るろうに剣心 -明治剣客浪漫譚-の登場人物一覧 主要人物
アニメ第1作では戦闘シーンが多く、警官を殴り倒すなど気の強さが大きく現れているが、伍兵衛に負けて無理矢理土地屋敷の権利書に拇印を押させられた時は自分の無力さに涙を流した。弥彦がヤクザに利用されていたことを知ると竹刀を手に乗り込んでヤクザたちと闘ったり、我介とやりあったりしている。また原作では観柳邸に乗り込まなかったがアニメ第1作では一緒に付いて来て観柳の私兵団と闘い勝利した。その他コメディリリーフの役割を担うことが多く、自分と似た性格の弥彦を弟みたいに思ったり、自分の美貌を自画自賛したりと原作における性格がより強調されている。風水編では入邪の法を受けて死の危機に瀕するも、剣心や陣風の尽力により一命を取り留める。
OVA『星霜編』では、剣心の抱える痛みを共有したいという前向きな気持ちから、不治の病に侵された剣心と接触し剣心の病が感染して剣心と同じ症状が表れる。
るろうに剣心 -明治剣客浪漫譚-の登場人物一覧 主要人物
人物像のモチーフは、坂本龍馬の恋人千葉佐那。
完全版第4巻の再筆：剣術小町っぽさを強調したデザイン。髪が直毛に近くなり、外見のイメージが変わる。家伝の短刀を帯に隠して身につけている。
キネマ版：神谷道場の土地が借地となっており、その権利を買い取った観柳により、賭博興行に立たされていた。原作と違い、料理が不得意という自覚がある。髪型が原作と若干異なっている。
実写映画版：基本的に原作に準じている設定がされている。自ら戦うシーンは少ないが、第2作目『京都大火編』では薙刀を使用して戦う姿も描かれた。
銀幕草紙変：料理が苦手な理由が以前は住み込みの門下生が作っており、門下生たちが出ていくまで料理をしたことがなかったためとされている。
るろうに剣心 -明治剣客浪漫譚-の登場人物一覧 主要人物
神谷活心流
父・神谷越路郎が創始した活人剣。相手を殺すのではなく制することを極意とし、殺傷力のある真剣ではなく木刀や竹刀を用いて戦う。また、刀身を一切利用せず柄で打撃を与える技もあり、奥義も柄を利用したものとなっている。原作第一幕では伍兵衛に『人を活かす剣』という理念を「寝言」と嘲られたが、後に剣心は自身の解釈として弥彦に「敗れれば、自身のみならず、守ろうとした人の命運も尽きる。『活人剣』を振るう者は、いかなる敗北も許されないということを肝に命じておくように」と諭した。アニメ第1作では柔術もこなす流派になっていた。
ここでは薫が使用する主な技をあげる。なお、弥彦の項で触れている神谷活心流の奥義「刃止め」「刃渡り」も技術的には習得しているが、実戦では使ったことは無い（一度も成功しないため）。
原作では偽抜刀斎事件のために門下生がいなくなったが、キネマ版では維新や廃刀令、文明開化で門下生がいなくなったという設定になっている。
柄の下段・膝挫（つかのげだん・ひざひしぎ）
柄を利用した膝関節破壊技（刀身が無くても使用可能）。下段の突進から相手の膝に柄による打撃を打ち込み、敵の膝を砕く。その威力は、打撃を打ち込む木刀の柄自体も粉々に砕け折れるほど。
京都編にて、十本刀「大鎌の鎌足」に対して使用し戦闘不能に追い込んだ。
神谷活心流柔術（アニメオリジナル）
るろうに剣心 -明治剣客浪漫譚-の登場人物一覧 主要人物
以下はアニメ第1作66話に登場した神谷活心流柔術。
木の葉返し（このはがえし）
地獄車（じごくぐるま）
巴二段投げ（ともえにだんなげ）
相楽左之助（さがら さのすけ）
声 - 上田祐司（少年期 - 渕崎ゆり子） / 八代拓（少年期 - 藤原夏海） / 関智一（少年期 - 結城比呂）〈CDブック版〉
演 映 - 青木崇高、宝 - 鳳翔大 / 真地佑果、松 - 植原卓也、京 - 岐洲匠
元・赤報隊一番隊準隊士で剣心の仲間。喧嘩屋をしていたが剣心と出会い改心した。初登場時19歳。
→詳細は「相楽左之助」を参照
明神弥彦（みょうじん やひこ）
声 - 冨永みーな / 小市眞琴 / 高山みなみ（CDブック版）
演 映 - 田中偉登（第1作）、大八木凱斗（第2・3作）、大西利空（第4・5作）、宝 - 彩みちる / 希良々うみ、松 - 加藤憲史郎 / 大河原爽介 / 川口調
身長128cm、体重23kg。1868年（明治元年）11月26日生まれ。東京府出身。血液型B、獅子座。初登場時10歳。趣味：稽古。好きな食べ物：牛肉・西瓜。一人称は「俺」。
るろうに剣心 -明治剣客浪漫譚-の登場人物一覧 主要人物
東京府士族の少年。明治維新の混乱によって孤児となった。30石2人扶持の下級武士だった父は彰義隊に加わって戦死、母は彼を育てるために遊郭で働き病死した。ヤクザに拾われ、スリとして働かされていたが、剣心たちと出会ってヤクザと離反。神谷活心流を学び剣心たちとともに戦うたび、幼いながらも常人離れした精神力・身体能力、剣才を発揮し成長していく。
ヤクザの一件から、剣心の計らいで神谷道場に入門させられる。当初は薫と言い争いが絶えなかったものの、薫が菱卍愚連隊の隊員2人を一撃で圧倒したところを目の当たりにしたことで考えを改め、その一件後に正式に門下生宣言をして鍛錬に取り組むようになる。
プライドが高く一本気な性格で、子供扱いされることを嫌う。敵味方を始め年長者に対しても物怖じしない発言をする（というよりも、誰に対しても敬語で話すことがほぼ皆無）ため、周囲からは生意気と取られている。早く一人前の男になりたいと強く願い、そのためには血の滲むような努力も厭わず、自分より力量が上の相手に対しても弱者を守るために立ち向かっていく勇気を持っている。作中では斎藤と直接交渉を行ったこともあり、蒼紫や斎藤も彼の度胸や胆力を評価している。本人は不本意ながらも、スリのセンスはあり、それが味方の危機を救うこともある。また、建物の軒下に長時間隠れるといった器用な一面も見せた。
るろうに剣心 -明治剣客浪漫譚-の登場人物一覧 主要人物
後に塚山由太郎と共に神谷活心流道場師範代を務め、「白刃取り千本制覇」「東日本でも五指に入る腕前」と称されるまでに成長（本人は日本二と自称。日本一は剣心とのこと）し、剣心からは逆刃刀と「不殺」の信念、左之助からは「悪一文字」の生き様をそれぞれ受け継ぐ。明治15年（1882年）時点での外見は、体格は剣心、性格は左之助のイメージでデザインしたとのこと。後に三条燕（後述）と結婚。
登場当初から高い実力を有しているキャラクターが多い本作品では珍しく、当初は単なる子供だったが稽古や実戦を通して強敵にも勝利を収めるなど成長過程が描かれている。
『明日郎 前科アリ（異聞）』では剣心と共に明日郎たちを助けに現れ、逆刃刀を剣心に貸している。事件解決後に警察から志々雄一派の残党に関する話を聞き、さらに明日郎と阿爛が神谷道場の預かりになったと話が付いた旨を語っていた。
『北海道編』では師範代が二人とも道場を空けるわけにはいかないとして東京に残留。その際に剣心の腕が鈍っていないか確認した後、「体力は落ちているが、剣腕は全く衰えていない」として正式に逆刃刀を剣心に返却。そのことで一抹の寂しさを覚えてそれを燕に看過されたことで、一緒に暮らすことを提案している。劍客兵器対策としては斎藤からも十代では別格の実力者と認め、目されており、剣心もいずれ召集するつもりではいるがまだその時ではないと保留している。