日記

基本的に，自分は個人ページの下であっても編集ボタンをグレーアウトさせない方針で運用していたのだが，
日記については閉じることにした．

また，ACLがページごとにバラバラだったのをなるべく揃うようにした．

undo

情報工学実験のある課題において undo を実装したいと思い，そもそも undo とはなんなのだろうかと考えていて思いついたこと．

全てのタスクは，状態 Q に対する fi の適用である．あるいは状態系 Q に対する メッセージ fi の送信 といったほうがより直感的かもしれない．

Q = ... fn・fn-1 ... f2・f1(Q0)

このとき，

• 状態系にメッセージfiを送信するとき，fi^-1 を同時に生成し，fi^-1 をスタック [T_undo] に積めば良い．
  

• 状態を戻したくなった場合，fi^-1 をスタックから取り出し，状態系にメッセージ送信すればよい．(そして fi^-1^-1 = fi を redo スタックに積む．)

これが undo なのだろうと思う．

redo スタックは，適切なタイミングで削除されなければならない．詳しく言うと，

• 今送信した fi が redo スタックの一番上に乗っている fj と等しくなければ，redo スタックを全て破棄すべきである．

• 等しかった場合，redo スタックから一つ取り出して破棄すべきである．

箇条書き

単なる箇条書きにも思考が現れるなあということに気づいた．

箇条書きには，手続き的なものと，構造的なものがある．

どちらもどちらかの決まりに従い続ければそれはそれで良く動く(that works)し，手続き的なものはしばし有用である．
しかし，ここで私は構造的に書くことを薦めたい．

手続き的に書かれた箇条書き [ln] は往々にして半順序である． これは，メンテナンス性が低いことを示し，かつここに新たに li を加えたいとき，順序が定義出来ないことが多々ある．

またそれ以上に本質的な問題として，何の意味を順序として用いるか(how semantically sorted)ということが，
「何を用いるか」「どのように用いるか」という重要な(そしてほぼ全てを占めている)面において，ほとんど個人の感性に依存してしまうという問題がある．

これが，上で「しばし」有用であると述べた意図である．手続き的な箇条書きは個人的なメモにおいてはしばしとても有用であるが，
それ以外の場面においてはおおよそ用いるべきでない．

一方，構造的に書かれた場合，そもそも順序が意味をなしていない．(ただし，現実においては「人間に対して見やすい」という意味を持っている場合がしばしある．)

したがって，予め与えられた構造系が追加されうる要素についてよく想定して設計されたものであれば，
要素追加は直感的で高速・効率的である．さらに，良い構造が自律的に保たれることもある．

したがって，多くの人から参照されるようなデータにおいては，構造的な箇条書きを用いるべきである．
もちろん，このとき構造化する指標を良く選び・良く共有することについては，よく注意を払わなければならない．