http://blog.judstyle.jp/article/48062448.html MML考(1)
今回は高機能MMLコンパイラから見た構文解析とエラーについて。
構文解析時のエラー処理についてはユーザ入力データを解析して変換する動作のアプリなら必ず付きまとう問題だけど、
(1)実行時エラーを許容するか
(2)どこまでエラーとするのか警告で済ますのか
(3)エラー情報をどこまでユーザに伝えるか
の3点については判断がすごく難しい。音源とMMLの仕様が決まっていれば、MMLコンパイラの仕様はだいたいここくらいしか考えるところがないといっていい。
(1)実行時エラーを許容するか
MMLコンパイルと(便宜上こう呼ぶとして)ドライバによる演奏の場合、演奏中にエラーは許されないので、演奏開始時のエラーということになる。データ不整合まあ必要なファイルが足りない(PMD/FMPならPCMファイルがない)くらいしか発生し得ないけど、内部データでパラメータを相対操作する仕組みにするとここで躓く。
相対操作なんて何に使うんだという点では、オートフィルタあたりが代表的な要素になるのだろうけど、オーバー/アンダーフロー制御をするのかしないのか、という問題が出てしまう。
とはいえ、実行時エラーは許容できないというのが現実的な回答なので、上限下限張り付きか、フロー許容で(たとえば8bitなら-128と127を)循環させるのかということになる。上限下限張り付きであれば、内部的には上限下限を超えて計算し続けるのか、上限下限で値を留め置くのかという問題も出るし、設定可能にすればユーザの手間が増える。
(2)どこまでエラーとするのか警告で済ますのか
構文エラーと論理的なエラーとデータエラー、未定義情報の取り扱いについて。defaultに関する議論でもあるので略。
(3)エラー情報をどこまでユーザに伝えるか
もっとも大きな問題は、エラー箇所の報告。長いMMLになってくると、どこでエラーになったのかわからなくなることがある。特に再利用・流用で大量のMMLを追加した直後のコンパイルで危ない。メタなMMLコマンドは展開してから構文解析したいが、展開してから構文誤りを見つけた場合に該当MMLをユーザに示してエラー報告してもユーザがわからない可能性がある。
ユーザにわかりやすい情報を示すためにはpass数を減らして、構文解析しながら論理解析して演奏データを作成することになるけど、高機能MMLコンパイラでそれをやろうとすると負荷が増える。MML入力でコンパイラの応答が悪いことは生産性に直結するので、バランスを取らなくてはならないなあ。FMP7のコンパイラの作りも、ここの制限を多分に受けてると思うけど。
----
実際にはMML記法やデータ設計も平行して進めないと解決はしないので、一発で答えが出ない検討ばかりしてるような気はする。
あと、高機能MMLは仕様が複雑化していくのでそこらへんも解決しないとなあ。自分しか使わねーよ、ということについてはともかく、新しいMMLを起こすたびに定義定義ではイヤんなっちゃう。デフォ値設定やincludeについては慎重にやっていかないと…
2011年09月30日
この記事へのコメント
コメントを書く
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/48253020
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。
この記事へのトラックバック
http://blog.sakura.ne.jp/tb/48253020
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。
この記事へのトラックバック