継続を伴った引数つきgoto

タイトルの実装方法が分からずに、ずっと止まってる。処理系のソースを読めば分かると思うけど、なんか悔しいので、自分で試行錯誤して作りたい。
まず「継続を伴った」に関して。継続渡し形式なんてものを以前に考えたことがある。それは「次に何をすべきか」を渡してやるプログラミングのスタイルだった。「次に何をすべきか」を渡してやるということは、つまり「次に何をすべきか」をあらかじめ用意しておく必要があるってこと。継続渡し形式でプログラムを書いている時は、時の流れが逆になったような違和感を感じながら書いていた。この「継続を伴った」ってのは、継続渡しを処理系がやってあげる必要があるんだと勝手に思ってる。んで、call/ccは処理系が作ったユーザが意識することの無い継続を捕まえる手段なんだろうな。継続をどう実装するのか決めてないけど。
次に「引数つき」に関して。今から評価する手続きに必要な情報だから、もちろん必要やね。実際は引数は全て評価された後、新しい環境フレームを作って、そのフレームで環境を拡張してやって、拡張された環境の下で手続き本体が評価される。だから、引数に関しては、特に今のところは大丈夫なような気がする。call/ccで継続が捕まえられると、環境フレームへの参照は生きつづけるので、その辺も考えないといけないんだろうね。
最後に「goto」の部分。これが非常に曲者だ。今はC#でのメソッドの呼び出しの機構に従っているので、例えば

(define eternity (lambda () (eternity)))

みたいな手続きを実行すると、スタックオーバーフローで異常終了してしまう（.NETでは、StackOverflowExceptionはcatchできない）。つまり、C#のメソッド呼び出しの機構をそのまま使ってはまずいということで、そのためにどういう方法があるのか考え中。C#のスタックのクラスを使ったら良いかと思ったけど、これはスタックの上限サイズが大きくなるだけで、根本的な解決にはならないような気がした。.NETやmonoにどれだけのヒープが割り当てられるかも関係するんだろうけど。そこら辺の事情はよく分からんんぁ。あと、そもそもスタックを使うことは「手続きの実行は、それが終了したら呼び出し元に戻って来る」っていう前提があるんだと思うので、継続を伴っている以上、スタックである必要は無いんじゃないかと思ってる。