[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[mhc:00655] Re: High-speed and improved MHC
乃村です。いろんな話でちょっと混乱してきました。
・ 複雑な日付記述をサポートするための、強力な言語が欲しい
・ 既存のヘッダの話 (X-SC-Next:, X-SC-Cond: を複数いれる?)
・ TODO はユーザにとって、どう見えるべきであるか
それらは、独立に検討していいですよね。
On Wed, 31 May 2000 07:10:26 +0900,
TSUCHIYA Masatoshi <tsuchiya@xxxxxxxxxxxxxxxxxxxxxxx> said:
まず、強力な言語のはなし。
> nom> これしかないのはやりすぎですが。MHC の元々のヘッダで、ほとんどの
> nom> 場合 OK なはずです。となると、第二の方法を使うのは、
> nom> かなり複雑なのを書きたいときです。どうせなら万能を目指すというのも
> nom> 1つの方法です。calendar.el とかも、そうじゃなかったっけ。
>
> ですから、どうせなら万能を目指すという立場をとるなら、自分の手で制限の
> 多い文法をわざわざ設計するよりも、S式という非常に強力な表記法を採用し
> ておく方が楽だと思います。
それは、その通りです。しかし、目的に特化した、いい言語が定義でき
れば、そちらの方が使いやすいのではないでしょうか。parser の苦労
はあまり考えていません。
その辺を一度検討した上で S式だという結論が出るならそれでいいですが。
# あ、それをふまえて、S式だというのが土屋さんの主張なのか。
うーん。ちょと、行き違いがあるかもしれない気がしてきた。。
この「強力な言語」 自体は、MHC の既存の X-SC- とは独立して存在さ
せたいです。そこには、プログラマが好む、意味的制約を含まない、
正直な言語にしたいです。その点は土屋さんも一致していると思います。
その上で、僕がしようとしている話は、S式でいいのか、
C ライクか文法がいいのかという話にすぎません。
あるいは、制約論理プログラミングのような言語が参考になるかもしれません。
以下は、既存の X-SC に関する話。
上の話に同意していただけるなら、既存の X-SC- に無理に手を入れる
必要はないと思いませんか?
> 土> でしたら、積和標準形に直すのはどうでしょう? つまり、1つのヘッダの中で
> 土> は AND 条件、並置されたヘッダは OR 条件とします。
>
> 土> ただまあ、こうすると予想されるのは、「第1、第3水曜日」という指定が面倒
> 土> じゃないか、ということなんです。
>
> nom> あ、そのとおり。基本的に、決めの問題ですから、
> nom> 解はいくらでもあるのですが、落とし所の問題ですよね。。
>
> それはそうなんですけど、parser が書けるように設計しないと…。
いや、もちろん parser が書けるということは大前提です。
僕の言ってる落し所というのは、
parser と user のどっちがどれぐらい頑張るかということです。
parser が嬉しくて、user が嬉しくないのはいやです。
ユーザが思った通りに書いたら、その意を汲んでくれる。
# 自然言語が一番ですがこれは、parser の荷が重い。
「普段よく使う表現」 はできるだけ簡単にかけて、
「そうでない部分は」、頑張れば書ける。
この点において、既存の MHC は 「普段よく使う表現」 に重点を置いて
がんばっています。「そうでない部分」 にはまだ手を付けていません。
ここは、「強力な言語」 の役割です。
なので、「そうでない部分」は、上の強力な言語に押し込めて、
既存の X-SC- の意味はそのままの方が使いやすいのではないでしょうか。
parser のコストは少々増えますが。
繰り返しになりますが、
> 従来のMHCは、この点について非常に頑張っていて、構文的束縛のみならず、
> 意味論的な束縛についても考慮することによって、解析が成り立っているわけ
> ですよね。
>
> 例えば、
>
> X-SC-Cond: 1st Wed
>
> は、2つの構文要素(1st,Wed)が同時に成立可能だからANDを表す、のに対して、
>
> X-SC-Cond: 13 Wed
>
> は、2つの構文要素が(一般的には)両立不可能だからORを表す、と意味的制約
> に基づく解析を行っていると考えられます。
>
> しかし、これは非常に努力の必要な方法で、parser にかかる負担はとても大
> きいです。例えば、「第1月曜日および第3木曜日」という予定はどのように書
> かれるべきでしょうか?
:
> そんなわけで、私の考えでは、設計者の内在する意味的制約をあまり前面に押
> し出さず、論理的な制約のみを用いて解析できるヘッダ設計をするべきだと考
> えています。ですから、
設計者の内在する意味的制約ではなくて、ユーザに内在する意味的制約
をうまく使ってユーザをスムーズに導くのが僕の趣味です。
もし X-SC を 2個使えるようにするなら、僕は、「第1月曜日および第3木曜日」
が必要なときになってはじめて 2行書かないといけなくなるというのが重要だと
思っています。
なので、この件に関していうと、X-SC-Cond: の解釈する意味は今迄通りで、
2行書いた場合はそれらを or でつなぐ、という案と、
そもそも 2個使う必要はない、そういう時は「強力な言語」 に任せる。
という案があって、後者が僕の 「落し所」 です。
既存の X-SC- をいじることに関しては、そういうことではなくて、
X-SC-Next: 相当の枠組が欲しいだけです。
具体的にいうと、
X-SC-Record-Id: <200005250958340255.nom@xxxxxxxxxxxxxxxxx>
X-SC-Schedule:
X-SC-Subject: ゼミ
X-SC-Location: A108
X-SC-Day: 20000531
X-SC-Time: 09:00-10:00
X-SC-Category: Seminar
X-SC-Cond:
X-SC-Duration:
X-SC-Alarm:
X-SC-Schedule:
X-SC-Expression: (today - 20000530) % 4 == 0 ;; 4日毎
X-SC-Alarm:
X-SC-Schedule:
:
という記述法 (見た目はもうちょっといじるとして)
で X-SC-Expression: の文法については、別途考えるというので
どうでしょうか?
TODO は、また別途。
--
nom