したがって、日本語処理ではひらがなをローマ字に変換してから形態素解析を行い、その結果をひらがなに戻すと簡単になるのだが、和欧混植（一つのテキストに和文と欧文が混在するもの）などへの対応が複雑になる。そのため音素ベースの文法記述を五十音図ベースの記述に変更すると、およそ四倍程度に膨らむ。 日本語処理に関しては、「長尾の法則」他いくつか知られているが[注 2]、根幹的・基幹的なものとして数学基礎論の島内剛一による「島内式ローマ字かな変換」がある。 すなわち、 [文法属性A] - {"パターンマッチング文字列X"|"変換後の文字列Y"} - [文法属性B]; といった行の並びによって、文字列に対するパターンマッチングによって文字列の変換を行うという手法である。「sa・si・su・se・so」と「shi」、「ta・ti・tu・te・to」と「chi・tsu」の両方をサポートするための記述の面倒臭さはあるが、変換精度は高い。ただし、変換結果としてのデータ構造はPERTにおける「ネットワーク図」（いわゆる、束と位相同型な半順序構造と位相同型なデータ構造）になるため、そうしたタイプのデータ構造を扱えるプログラマが稀少であるという問題がある[注 3][注 4]。 マッチングパターンの記述はファイル上一行で書くことができる。その点についてはPrologに近い。ただし小規模のプログラムにおいては問題がないが、実行順序が指定されておらず、出力結果であるネットワーク構造が正しく半順序構造になっているかについての検証をどう行うかという課題がある。反面、文法記述には実行順序に対する規制がないため、複数のファイルを実行時に（動的に）切り替えることができる。このとき、「巡回参照があるかどうか」を動的にチェックする（この場所が以前通ったところであるかをチェックする）か静的にチェックする（あらかじめ、文法定義においてヌルストリングとマッチした場合に巡回参照がないかどうかをチェックする）かによって実行効率が変わってくるため、実装上の判断が必要になる。 このとき、有効なのは「文字列の何文字目か」という距離空間を持ちこむことであるが、マッチング文字列がヌルストリングであった場合に問題が起こりうるという点である。実例としては、「書いている」を「書いてる」と略した場合、「いる」の語幹「い（i）」が省略されているとして文法記述を行なうと、「動詞の連用形は用言に係る」という規則と競合し、「書いて」と「る」の間に無限個の省略された「（い）」があると解釈されてシステムが落ちるという事例があった。なお、このケースでは動詞の連用形過去または完了形の活用語尾に「いる」の省略形を追加することで回避した。同じく補助動詞である「おく」（置いとく）「ゆく」（持ってく）では、語幹にあたる「ok」「ik」「yuk」が省略されても文法記述と交絡しないので、こうした問題は発生しない。
技法
課題
脚注[脚注の使い方]
注釈^ 実際に インプット メソッド エディタでローマ字入力を行なっているときは、システム内部ではこれに近いことを行なっている。
^ 橋田浩一によれば、「かな漢字変換はブラックアートである」という。
^ ネットワーク型のデータの扱いに熟達していて、同時に国文法に対するプログラマというのは、かなりのレアケースであり、そうした人員が日本語処理系の開発プロジェクトに携わるというのは、さらに稀である。「盲亀の浮木」「うどんげ」などを参照のこと。
^ もっとも、初期のかな漢字変換においては「接続テーブル法」という手法が使われており、「どの品詞のあとに、どの品詞がくるか」という二次元のテーブルを使用していたのだが、品詞分類が増えると品詞の数の自乗に比例してテーブルが大きくなり、しかもテーブルがスパース（「スカスカ」）だったために扱いきれなくなった。そのため、島内式ローマ字かな変換を元に文法定義を中間言語によって記述するという発想が生まれたという経緯がある。
出典^ 石田信一「コンピューターによる新聞紙面製作
^ ⇒漢字・日本語処理技術の発展：日本語ワードプロセッサの誕生とその歴史
参考文献
『日本語処理機能』 - コトバンク