[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[mhc:00646] Re: High-speed and improved MHC
>> On Wed, 31 May 2000 01:04:23 +0900
>> "nom" == nom@xxxxxxxxxxxxxxxxxxx (Yoshinari NOMURA) said as follows:
土> X-SC-Sexp: (if (day 20000531) (subject "研究会発表"))
nom> 実は、このやり過ぎもありかなと思っています。
nom> Sexp は、elisp に寄り過ぎるので、適切な文法を定義してやるのはどうでしょう。
根本的には、parser が書けるかどうかが問題です。S式の形式にしておけば、
式中に現れるシンボルを Emacs-Lisp の実在の関数のシンボルに置換するだけ
で、条件ヘッダの関数表示を得ることができます。が、そうではなく、適当な
文法を定義するというのであれば、それを処理する parser を書く必要があり
ます。
nom> これしかないのはやりすぎですが。MHC の元々のヘッダで、ほとんどの
nom> 場合 OK なはずです。となると、第二の方法を使うのは、
nom> かなり複雑なのを書きたいときです。どうせなら万能を目指すというのも
nom> 1つの方法です。calendar.el とかも、そうじゃなかったっけ。
ですから、どうせなら万能を目指すという立場をとるなら、自分の手で制限の
多い文法をわざわざ設計するよりも、S式という非常に強力な表記法を採用し
ておく方が楽だと思います。
誤解のないように付け加えておくと、表記としてのS式と、内部の述語関数の
設計とは別だと思っています。具体的には、私のイメージでは、
;; 2000年5月29日の場合に真
(day-is 20000529)
;; 月曜日の場合に真
(monday-p)
といったような、従来のMHCの条件ヘッダで表されていたような条件を表す述
語関数と、if, and , or , cond などのような特殊表現、および、特定の変数
(拡張版でS式を評価するときに束縛されている変数)に対する参照のみを許す
ようにします。
nom> 実際の所、他の人は、どんなデータが MHC では記述できずに困ってい
nom> るのか調査したい所ですね。僕が書きたいのは、公務員の給料日。
こういったややこしいものは、条件ヘッダが事実上プログラムとしての表現能
力を持っていなければ出来ませんから、なおのこと、自力で文法を書くのは難
しいでしょう。
土> でしたら、積和標準形に直すのはどうでしょう? つまり、1つのヘッダの中で
土> は AND 条件、並置されたヘッダは OR 条件とします。
土> ただまあ、こうすると予想されるのは、「第1、第3水曜日」という指定が面倒
土> じゃないか、ということなんです。
nom> あ、そのとおり。基本的に、決めの問題ですから、
nom> 解はいくらでもあるのですが、落とし所の問題ですよね。。
それはそうなんですけど、parser が書けるように設計しないと…。
従来のMHCは、この点について非常に頑張っていて、構文的束縛のみならず、
意味論的な束縛についても考慮することによって、解析が成り立っているわけ
ですよね。
例えば、
X-SC-Cond: 1st Wed
は、2つの構文要素(1st,Wed)が同時に成立可能だからANDを表す、のに対して、
X-SC-Cond: 13 Wed
は、2つの構文要素が(一般的には)両立不可能だからORを表す、と意味的制約
に基づく解析を行っていると考えられます。
しかし、これは非常に努力の必要な方法で、parser にかかる負担はとても大
きいです。例えば、「第1月曜日および第3木曜日」という予定はどのように書
かれるべきでしょうか?
また、記述可能である条件の種類が増えてくると、設計者の意図する意味的制
約を組み合わせる順序問題が爆発してしまうため、結局、固定された順序で制
約を組み立てるしかありません。が、そうすると、意図しない記述法が行われ
た場合に破綻しやすい、ということが予想されます。
そんなわけで、私の考えでは、設計者の内在する意味的制約をあまり前面に押
し出さず、論理的な制約のみを用いて解析できるヘッダ設計をするべきだと考
えています。ですから、
nom> X-SC-Cond: 5 15 25 ;; 「5の付く日」
が、
X-SC-Cond: 5
X-SC-Cond: 15
X-SC-Cond: 25
となるのは、私の考えでは当然だと思います。
また、mhc-draft-mode に、ヘッダの補完入力機能を追加すれば、同じヘッダ
を複数個記述する場合でもそれほどの労力にならないようにすることは可能で
しょう。
土> と、よく考えてみると、X-SC-Duration: が導入されている理由が分からなく
土> なってきますね。X-SC-Cond: で指定される他の構文要素と判別可能なので、
土> 統一できるのではないでしょうか。
nom> そうですね。そういう意味では、Date: も Cond: とまとめられます。
nom> これは、見た目です。
ですが、これに付随する意味的制約を持ち込んでしまうと、ヘッダの設計が破
綻しかねないので、何らかの標準形に直すのでなければ、統一するべきではな
いでしょうね。
nom> X-SC-Day: 20001201-20001205 ;; これは、便宜上の嘘ね。
nom> X-SC-Subject: 1st MHC International Conferenece
nom> X-SC-Location: 九大
nom> X-SC-Next:
nom> X-SC-Day: 20000630
nom> X-SC-Subject: 論文提出締切
nom> X-SC-ToDo: 100
nom> X-SC-Next:
nom> X-SC-Day: 20000930
nom> X-SC-Subject: カメラレディ締切
nom> X-SC-ToDo: 100
nom> と書きたい。こう書くと、TODO の表示欄には、常に DONE になるまで
nom> 表示していてほしい。
nom> 1年後に締切があるような TODO をどこに置くかということになりますが、
nom> 土屋さんの意見は、 Duration: で 1年後を指定しといて、
nom> intersect/ に入れようということですね。それとは別に、
nom> 締切をスケジュールにも出したい場合は、Next: でもう1個書くということですね。
nom> それって、1個記事が増えるだけで、嬉しくなくないですか。
ちょっと、この心が分からないのですが。
nom> 普通締切のある TODO はスケジュールに載せたいでしょう?
nom> 締切がない場合は、書かないから schedule にも出ないので、
nom> ハッピーだと思うんですけど。
nom> うーん、やっぱり TODO のときは、Day: を Deadline として扱うのが
nom> いいのでは? すると、schedule 上にも素直に反映させることができる。
nom> Day: は X day なのです。TODO でいうと、締切。
ああ、そうか。
私は、『TODO が表示される日付範囲を規定する目的で、現在の MHC の条件ヘッ
ダを流用する』という視点で考えているのに対して、乃村さんは『TODO を規
定するような、あるべきヘッダの設計について考える』という視点で考えてい
らっしゃるようですね。
しかし、そのようにすると、TODO の場合と、それ以外のスケジュールの場合
で、ヘッダの解釈が全く異なる、つまり、parser を2通り実装する必要が発生
するわけなので、実装面からは嬉しくないと思います。
そうすると、X-SC-Deadline: というヘッダを新設するか、
X-SC-ToDo: 100 deadline=20000701
というような拡張記法を持ち込むか。まあ、設計思想の問題なんですけど。
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
http://www-nagao.kuee.kyoto-u.ac.jp/member/tsuchiya/