Gauche:デバッガ

Gauche:デバッガ

GaucheにデバッグAPIを組み込むに当たり、よりよいインターフェースや実装などを議論するためのページです。

などのアイデアがあればどんどん書き込んでください。

(以前の内容はデバッガに移されました)


議論にあたっての制約と目的について

Shiro(2008/11/19 02:47:17 PST): エンジニアリングはトレードオフです。 重要なのは色々な方法を考えることではなく、 考えた方法のうちから与えられた制約と目的にベストフィットするものを 選択することです。つまり制約と目的が明らかでない段階での議論は無意味です。 デバッガ一般の話ではなく、Gaucheについて考える場合は、 Gaucheの制約と目的を踏まえて議論をお願いします。

最後の二つは特に重要で、実行モデルに合ったデバッグ手法をプロモート するようなデバッガでないと、無理なコーディングを奨励することになりかね ないので注意してください。むしろ既存のデバッグ手法から離れて新たな デバッグ手法の提案が出ることを期待します。

例えばTCOの存在下では「ソースコードの字面に対応するスタックトレース」は そもそも存在しないわけで、それを取れるようにしようと頑張るのは間違いだと思います。 (そこにスタックトレースを期待している時点で、プログラマの頭の中のモデルが 違っています)。 むしろSchemeのモデルなら、チェックポイントの通過履歴を取っておく、 というような概念の方が良いかもしれません。

また、ステップ実行というのはそれほど重視すべきではないと思います。 むしろcontractを宣言的に付加してそれが 破れた時にbreakする、というのが主なインタフェースであって、 そのおまけとして次のチェックポイントで無条件breakする機能(=ステップ実行) が付属する、みたいな見せ方にすべきだと思います。

ほぼ関数型スタイルで書いてあるコードでステップ実行が本当に役に立つ場面というのは 限られていて、たぶんそれが必要なのはエキスパートだけです。 初心者にはステップ実行は難しすぎて使えないくらいの方がきっと良いのでは。

そもそも「ステップ実行してその都度状態を調べる」という手法が手続き型思考って 感じがするんですな。関数的にとらえれば、状態変化とは新たな世界の生成です。 ということは変化した世界すべてを記録しておけば、あとから変化を逆向して 調べることも、任意の世界を指定してその状態を再現することも可能なわけで。 だとしたらそういう機能 (世界のスナップショットを残す、とか 副作用について履歴を残す、とか) いう機能を重視すべきかもしれません。

絶対に必要なAPI

あると嬉しいかもしれないAPI

実装についてのアイデア

実装上の難しい問題など


Post a comment

Name:


Last modified : 2009/01/30 12:10:35 UTC