現状:
    non-dollar要求 (errNum 336)
      => 最左端・最右端の$については特殊な判定を行えば良い
      => Condition風の判定をすればよい

    aimezバグの原因は？
      => sample_aimez_buggyにおいて、2行目の`"ez" ^ -> /e/;`によって "ez"というStat素が構成されているので、それが4行目 ` "m" ("a" | "e" | "i" | "o" | "u" | "y") -> /m/ $` の判定に引っかからない
    なぜ引っかからない？
      => 仕様書の4-4-2-2.を見てみよう。
4-4-2-2.「『文字列の集合とPHONEMEの対』のリスト」のとき
まず、「変換関数」を定義する。変換関数は、「PHONEME」「パターン文字列」「Stat対」を受け取り、「Stat対」を返したり返さなかったりする関数である。（「Stat対または未定義値」を返す、と言ってもよい）
「Stat対のfstの後ろからk個のStat素を削り落とすと、その削り落としたところのconcatがパターン文字列と一致する」となるようなkが存在しないなら未定義値を返す。
存在するならば、

具体例を見てみよう。
まず、PHONEMEが$である場合。パターン文字列が"a"、Stat対が次のようなものであるときを考える。
(
"c" "a" "n" "a"
nullnullnullnull
,
"l"
null
 )
この時、Stat対のfstの後ろから1個のStat素を削り落とすと、その削り落としたところのconcatは"a"であり、パターン文字列と一致する。
ゆえに、変換関数は以下のStat対を返す。
(
"c" "a" "n"
nullnullnull
,
"a" "l"
nullnull
 )
要するに、 "m" ("a" | "e" | "i" | "o" | "u" | "y") -> /m/ $ の$通過後に、
(
"ai" "m"
"ɛ"null
,
"ez"
"e"
 )
があってほしい。ただ、"m" ("a" | "e" | "i" | "o" | "u" | "y") !"q" -> /m/ $ の$通過後にも
(
"ai" "m"
"ɛ"null
,
"ez"
"e"
 )
があってほしいし、逆に"m" ("a" | "e" | "i" | "o" | "u" | "y") !"z" -> /m/ $ の$通過後には
(
"ai" "m"
"ɛ"null
,
"ez"
"e"
 )
があってほしくない。




じゃあどうするか？
とりあえず、「右ドル」「左ドル」を分離したデータ構造にしてみよう。
「仕様は特に変えず、データ構造だけとりあえず変えてみる」か。まずは。
errNum 336ってどこで出してるんだっけ
Sents_to_rulesの63行目か。
Wed Jun 21 18:29:11 2017 JST とりあえず、データ構造は変えた。これからいじる。

Sun Jun 25 09:46:54 2017
さて、データ構造を変えたところで、どういじっていくべきか？
まず右側を処理しよう。
今までは、「全パターンでの切り分けを生成し、右条件とその左の$たちを次々通過させる」という処理だったが、
これを「右$と右条件を満たすパターンだけ生成する」にすれば良いのでは？
じゃあ実装していこう

Sun Jun 25 10:35:34 2017
再帰的に通すのではなく、cutlist statで全パターン生成してそれを右$と右条件に叶うかチェックする方針にしようと決め、
コードをそういう風にする。

Sun Jun 25 12:26:27 2017
説明を書いて、その中でこのページに書いた例も引用。さて次は左側だ。
右側は「全部生成して、その中で右側を『既に満たして通過した』と見えるようなものだけ残す」という方針だった。
左側は逆に、「右と真ん中を通過したものの中で、『将来左を通過してくれるだろう』というものだけ残す」という方針になる。

Thu Jun 29 12:33:38 2017
空文字列でバグっていてつらいが、バグは自然治癒するものではないので手を入れていきたい。

Tue Jul  4 23:57:29 2017
空文字列バグは直っていないが、ZpDICとの兼ね合いでアプデとする。互換性が切れているので注意。