khfdpl_result1

KH-FDPL の結論

• (by K, 2016.10.25)

(1)

• KH-FDPLはいわば#defineだけで機械語（とはいわないまでも、単純なアセンブラみたいな言語）に置換することを目指していた。
• しかし#defineでは以下みたいなことができる。

  #define FOR(a, b, c)  for (a = b; a < c; a++) {
  #define NEXT          }

• こういうことをされると、中カッコの入れ子関係は処理系には容易にはわからなくなってしまう。それでいいのか。
• 正常に動く場合はいいかもしれないけど、エラーがある場合はどうなのか。もはや要領を得ないエラーしか出せないのではないか？

(2)

• 次の問題。

  #define a + b  ADD(a, b)

• たとえばこういう記述ルールを書きたいのだけど、果たしてこれは可能なのか。例えばこういうのを考えてみる。

  (1+2)+3

• もしカッコを特別扱いしないのであればこれは、ADD((1,2)+3)になりはしないか？
• これを避けるにはどの#defineから適用するかを決定したり、どこで語が切れるのか、カッコは複数の語をひとかたまりにすることができることを、固定されたルールにする必要がある。

(3)

• そんなこんなで、とにかく#defineでカッコの合計数が増減するのはいけないことだと思った。それで、

  #define FOR a=b TO c d NEXT    for (a = b; a < c; a++) { d }

• とすることを思いついたのだけど、この場合、FORを入れ子にされても対応関係がちゃんととれるのか？

  FOR i=0 TO 10
    FOR i=0 TO 10
      hoge
    NEXT
  NEXT

• 最初のFORが最初のNEXTと対応しないなんてどうしてわかるだろう。
• だめだ。全然だめだ。

(4)

• 結局、()や{}は単純な置換によってどうこうできるものじゃないんだ。ここをどうにかしようと思ったのが敗因だ。
• 構文を超越できる#defineは悪なんだ。これを一切許さないようにしたほうがいいくらいなんだ。
• そうとも、#defineなんて引数が複数回評価されてしまうことがあったりして、諸悪の根源だ。
• よし#define的なものを一切許さない言語を作ろう。それでどこまでできるかを考えよう。→Essen

(5)

• でも今にして思えば、カッコや中カッコの規則を壊さない範囲でなら、置換方式で押し通すことも無理じゃない気がする。むしろその方がシンプル？
• 副作用があるかもしれない問題については、一度一時変数で受け取っておいて、その一時変数を使ってあれこれとやって、最後に一時変数を解放すればいいだけだと思う。
• じゃあ、KH-FDPLを見限ったのは早まった判断だったかも。
• Essenの中で復活させてみるかな・・・。

(6)

• 置換で頑張る方法だと、どうしてもコンパイラ的になる。そしてEssenは変数に型がないので、許されるすべての型のどれが来てもいいように、たくさんのifが必要になる。そうすると、コンパイルっぽいやりかたをするメリットはほとんどない。

KH-FDPLのWikiについて

• ということで、KH-FDPLは終了したわけですが、しかしKH-FDPLのWikiの中には、すでにpersistent_Cが居候しており、さらにEssenやuxfも間借りしていて、Wikiだけが使われ続ける状態になっています。