音長を扱う柔軟な文法は難しい

いま実装しているMMLの文法では、ユーザー定義マクロに型付き引数を指定することができて、その引数型は整数であったり音長であったりする。cdefgabもマクロで定義していて、これはキーを引数に取るnコマンドにキーをアサインしただけのものになっている。cdefgabを実装するには、その最初の引数 = 音長は、音長として解釈されなければならない。"c4"は、ドを4ステップではなく、ドを4分音符で発声、の意になる。

音長を引数として渡すことが出来るというのは、トークン解析のレベルでは実装したけど、音長と数値はかなり融通させなければならない（要するにキャストしなければならない）場面が多々ある。そして困ったことに、音長は大抵の場合は数値としてトークナイズされている（"c4"の"4"が数値になるか音長になるかは、マクロを展開した時に初めて分かる。引数の型調整をぼやかしていたおかげで、音長から数値に変換してさらに音長に変換するようなマクロ展開処理があると、4（分音符）→192/4 = 48（ステップ）→（数値の）48→48分音符として解釈(!) のような事態が生じる。

どう整理したものやら...過去に存在していたMML文法で、それほどマクロ展開をメタに定義した文法が存在していなかったのも頷けようというものだ。ややこしいもの。

音長の関係でもうひとつややこしい要素を発見した。和音だ。FM音源などモノフォニック音源を対象にしていたMMLには、そもそも和音の概念が無いが、たとえばmucではc0d0e4のように記述できる。cとdの発音長はどこから拾っているのだろうか?　これはe4までMMLを解釈しないと知り得ない。これは、cとdとeを別々の命令として解釈していて、命令のつながりから意味を再構築するようなステップが無いうちは、決して実現出来ない。そしてその意味論的再構築のステップを用意するとしても、その再構築ルールを定義する文法が必要になるということでもある(!)。これは現実的には不可能で、せいぜいコンパイラの拡張モジュールというかたちでinjectさせるくらいしかできない。

ここまで実装が進めばようやく先に進められるだろうと思っていたところに困った問題がたくさん。ホントどうしたもんだろ。