Gauche:デバッガ
GaucheにデバッグAPIを組み込むに当たり、よりよいインターフェースや実装などを議論するためのページです。
- こんな機能が必要
- この実装だとXXXの問題が避けられる
などのアイデアがあればどんどん書き込んでください。
(以前の内容はデバッガに移されました)
議論にあたっての制約と目的について
Shiro(2008/11/19 02:47:17 PST): エンジニアリングはトレードオフです。 重要なのは色々な方法を考えることではなく、 考えた方法のうちから与えられた制約と目的にベストフィットするものを 選択することです。つまり制約と目的が明らかでない段階での議論は無意味です。 デバッガ一般の話ではなく、Gaucheについて考える場合は、 Gaucheの制約と目的を踏まえて議論をお願いします。
- 実行時性能重視。デバッガの存在が実行時にペナルティにならないこと。
- プロダクション投入可能な実行コードを直接デバッグできること。 デバッグ用に別にコンパイルしなおす、ということはしない (ただし、実行性能に影響を与えるようなinstrumentを限定的な範囲で コードに埋め込む、というのはあり)
- 手続き型言語のデバッグ手法に引きずられて実行モデルを歪めないこと。
- 言語、処理系の動的な性質を活かしたデバッグ手法を優先すること。 (上記の限定的な埋め込みをon-the-flyの再コンパイルで実現するとか)
最後の二つは特に重要で、実行モデルに合ったデバッグ手法をプロモート するようなデバッガでないと、無理なコーディングを奨励することになりかね ないので注意してください。むしろ既存のデバッグ手法から離れて新たな デバッグ手法の提案が出ることを期待します。
例えばTCOの存在下では「ソースコードの字面に対応するスタックトレース」は そもそも存在しないわけで、それを取れるようにしようと頑張るのは間違いだと思います。 (そこにスタックトレースを期待している時点で、プログラマの頭の中のモデルが 違っています)。 むしろSchemeのモデルなら、チェックポイントの通過履歴を取っておく、 というような概念の方が良いかもしれません。
また、ステップ実行というのはそれほど重視すべきではないと思います。 むしろcontractを宣言的に付加してそれが 破れた時にbreakする、というのが主なインタフェースであって、 そのおまけとして次のチェックポイントで無条件breakする機能(=ステップ実行) が付属する、みたいな見せ方にすべきだと思います。
ほぼ関数型スタイルで書いてあるコードでステップ実行が本当に役に立つ場面というのは 限られていて、たぶんそれが必要なのはエキスパートだけです。 初心者にはステップ実行は難しすぎて使えないくらいの方がきっと良いのでは。
そもそも「ステップ実行してその都度状態を調べる」という手法が手続き型思考って 感じがするんですな。関数的にとらえれば、状態変化とは新たな世界の生成です。 ということは変化した世界すべてを記録しておけば、あとから変化を逆向して 調べることも、任意の世界を指定してその状態を再現することも可能なわけで。 だとしたらそういう機能 (世界のスナップショットを残す、とか 副作用について履歴を残す、とか) いう機能を重視すべきかもしれません。
Post a comment