メッセージ。 - ちょこっとSchemeの継続について
# ちょこっとSchemeの継続について
Schemeにおける継続の概念が、少し前にようやく理解できた気がした。そのように感じたきっかけは、自分でScheme処理系のオモチャを作ったことにある。ただ、継続というものがプログラミング言語にとって本質的なものなのかどうかが今でも分からない。ぼくのボンヤリした頭ではなかなか本質というものが理解できないのだけど、ふと思い出したときにはそのことについて考え楽しんでいる。
それともう1つ考えていることは、「どうして以前の自分は継続について理解できなかったのだろうか」ということ。なんとなく思い当たることの1つは、Schemeの仕様書がプログラミングの静的記述方法と解釈系だけではなく、実行インスタンスであるバーチャルマシンを実装するよう書かれていることを理解できなかったからではないかという気がする(この解釈であってますかね? ちゃんとR5RSを読んだことがないので間違ってる可能性あり)。
つまり以前のぼくは、C言語やPerlやPHPのようなバーチャルマシンなしで実行するプログラミングパラダイムの範疇内でSchemeを理解しようと試みていた。えーと、ここで「バーチャルマシン」と言っているのは、スタックマシンというか、Schemeレベルでの変数テーブルと実行スタックを意識した実装の方式という感じなのだけど。C言語やPerlやPHPでは、各々の言語レベルで変数テーブルやスタックを意識しなくてよいですよね?
それらの言語では、プログラマが記述したコードが、どのようにマシン語に落とされて実行されるかだけ意識しておけばよい。つまり、実マシンのスタックやメモリ状態だけを意識するというか。Schemeでも、継続を使わないプログラムであれば、C言語やPerlやPHPと同じように考えればよいけど、継続を使うコードとなるとどうしてもScheme処理系が自前でスタックを管理しているイメージ抜きには、動きを理解できた気になれないように思う。
で、そのへんの「自前でスタックを管理しているイメージ」ってのがさっぱり頭の中になくて、C言語とかのパラダイムでSchemeの継続を理解しようとしていたから、先へ進めなかったのかなぁ、と。どうなんでしょ。なんとなく思ったのでメモ。あ、それと途中で思ったけど、「実行インスタンスであるバーチャルマシン」という表現は、間違ってるかなぁ。「自前のスタックマシン」というぐらいの表現が近いかも。うーん、よく分からん。ぼくの知識では雲をつかむような話になってしまう。
それともう1つ考えていることは、「どうして以前の自分は継続について理解できなかったのだろうか」ということ。なんとなく思い当たることの1つは、Schemeの仕様書がプログラミングの静的記述方法と解釈系だけではなく、実行インスタンスであるバーチャルマシンを実装するよう書かれていることを理解できなかったからではないかという気がする(この解釈であってますかね? ちゃんとR5RSを読んだことがないので間違ってる可能性あり)。
つまり以前のぼくは、C言語やPerlやPHPのようなバーチャルマシンなしで実行するプログラミングパラダイムの範疇内でSchemeを理解しようと試みていた。えーと、ここで「バーチャルマシン」と言っているのは、スタックマシンというか、Schemeレベルでの変数テーブルと実行スタックを意識した実装の方式という感じなのだけど。C言語やPerlやPHPでは、各々の言語レベルで変数テーブルやスタックを意識しなくてよいですよね?
それらの言語では、プログラマが記述したコードが、どのようにマシン語に落とされて実行されるかだけ意識しておけばよい。つまり、実マシンのスタックやメモリ状態だけを意識するというか。Schemeでも、継続を使わないプログラムであれば、C言語やPerlやPHPと同じように考えればよいけど、継続を使うコードとなるとどうしてもScheme処理系が自前でスタックを管理しているイメージ抜きには、動きを理解できた気になれないように思う。
で、そのへんの「自前でスタックを管理しているイメージ」ってのがさっぱり頭の中になくて、C言語とかのパラダイムでSchemeの継続を理解しようとしていたから、先へ進めなかったのかなぁ、と。どうなんでしょ。なんとなく思ったのでメモ。あ、それと途中で思ったけど、「実行インスタンスであるバーチャルマシン」という表現は、間違ってるかなぁ。「自前のスタックマシン」というぐらいの表現が近いかも。うーん、よく分からん。ぼくの知識では雲をつかむような話になってしまう。
Comment
Trackback