K.Maebashi's BBS 管理者削除

> こういうtry関数をライブラリで用意することで、アプリケーション側では > こう書けるのかなあ、と。 ははあ、なるほど。 Java や C++ の例外の場合、例外の受け手は直接指定せず、受け手が 存在しない場合はトップレベルまで伝搬するわけですが、こういう風に 書くと、それとはだいぶ意味的に違うものになりそうです。 Java や C++ の例外処理機構と意味的に同じものは、ラベル指定の break 機能と、Lisp で言う unwind-protect (Java の finally) があり、処理系 側がトップレベルで break に使うラベルを何か定義してくれれば、 一応ライブラリレベルで、実装はできるとは思います。 ただ、その場合、例外の種類を表すものはグローバル変数 (あるいは スレッドローカル変数) で保持することになり、また、例外の伝搬を 実装するために、クロージャのリストも管理することになるんじゃ ないかな… 例外の catch は、finally 節内で、例外の種類を保持する グローバル変数を参照するだけで、できそうです。 でも Lisp みたいなマクロがないと、文法的に結構面倒くさそうなので、 言語レベルで定義しちゃった方が、むしろ好ましいかもしれませんね。 > Lispはレキシカルスコープでもクロージャの受け渡しができるわけでしょうか。 > Lispのマクロは、「コードを示すリストをプログラムからいじること」という > レベルでしか理解していないです。throwに相当するシンボルをさくっと > 置き換えればよいのかな。 catch & throw は、throw する先を表すキーとしてシンボルを 使うわけですが、このキーとクロージャの対応を管理する連想 リストは、関数呼びだしのネストに従って、スタック式に管理 します。この連想リストは、言語が提供するものではなく、 ライブラリが内部的に管理する単なるデータ構造に過ぎないので、 レキシカルスコープとは関係ないわけです。