MML文法のクセを決める重要な要素の一つが、マクロトークンをどう解析するかである。
通常のプログラミング言語とは異なり、MMLは命令呼び出しが連続する。典型的なMMLを考えてみよう: o4cde そして、命令語が短いこともひとつの特徴だ。たとえば、連続的なピッチベンドの変化を記述するのに、"B0c24,1B50r24B-50r24B50r24B-50..." と書くことはできても、"pitchbend(0) c24,1 pitchbend(50) r24 pitchbend(-50) r24 pitchbend(50) r24 pitch_bend(-50) r24 ..." と書いてはいられない。(実際にはこのような記述は動的パラメータ記述を用いて簡略化されるべきではあるが。) 連続的記述と、短い命令語という特徴を組み合わせると、トークン解析が困難になるという問題がある。たとえば、次のようなマクロが定義されていたとする: このとき、"ABCDE"という文字列をどうtokenizeするかは、自明ではない。正規表現検索においても、この種の問題はつきまとう。これを解決するアプローチはいくつか考えられる: 前2者のアプローチに比べて後2者のアプローチは厳密で、MMLが作者の意図しないかたちで解釈される可能性を小さくするが、厳密に過ぎるため、マクロが長くなる、あるいは表現力が狭まる、といった傾向がある。 また、マクロの名前参照をどう解決するかについても、2つのアプローチが考えられる。 20世紀の頃はメモリリソースの問題も無かったわけではないので、ストリーミング処理を意識して前者のアプローチが好まれたこともあったかもしれないが、現代的には後者でほぼ問題が無いだろう。ただし、連続的なマクロトークンを解決するためには、内容解析のステップで参照の解決も行わなければならない(連続記述を許さない方式など、識別子の区切りが明確になる場合はその限りではない)。 ちなみに、大文字と小文字を区別しない文法もあるが、識別子が長くなる傾向がある。 さて、どの方式が最も望ましいか、自分では決めかねている。一方で、これらは文字列を解析して構文ツリーを構築するまでのステップで終わる話でもある。たかだかパーサ/トークナイザのレベルの問題で、利用者を絞り込んでしまうというのはもったいない。 実のところ、これらは選択的なものとして実装することが可能なのではないかと思っている。先にマクロ参照される名前のリストさえ保持できていれば、後は解決アプローチをpragmaで設定しておくことで、ユーザ好みの解決がはかれるだろう。とりあえずその方向性で考えている。 大文字と小文字を区別しない文法も提供可能だ。解析時に全てのシンボル参照を小文字に置き換えるだけでよい。