関数型言語のスタックの扱いについて、調べていた。ちょっと衝撃。
まずびっくりしたのは浅い束縛と深い束縛だ。深い束縛というのはCと同じよう な感じでスタックフレームを形成していく。そしてここでCにはないのは、呼び 出された先からスタックを登って変数を参照することだ。
なんでこんなことをするのかというと、LISPは動的に変数を拾ってくるから。 これはクロージャの時だろう。クロージャは関数+状況なので、クロージャが定 義された時のスタックフレーム上の値を参照するのにスタックを上らないとい けない。浅い束縛はスタックフレームではなく、その変数名に対して値のキュー としてとっておく。このキューを走査して値をとる。(これ、実行状況がよくわ からない)
そもそもこんな操作は絶対したくない。これに対してSchemeは静的らしい。つ まりクロージャができた時点でその参照した値になる。
やっぱりUsing Continuations to Implement Thread Management and Communication in Operating Systems.にあった通り、ちょっと、言語系とは違 うかな...。
実際のとこ、そこまでスタック操作した性能の劣化以上の何かがあるようには 思えない。
まずびっくりしたのは浅い束縛と深い束縛だ。深い束縛というのはCと同じよう な感じでスタックフレームを形成していく。そしてここでCにはないのは、呼び 出された先からスタックを登って変数を参照することだ。
なんでこんなことをするのかというと、LISPは動的に変数を拾ってくるから。 これはクロージャの時だろう。クロージャは関数+状況なので、クロージャが定 義された時のスタックフレーム上の値を参照するのにスタックを上らないとい けない。浅い束縛はスタックフレームではなく、その変数名に対して値のキュー としてとっておく。このキューを走査して値をとる。(これ、実行状況がよくわ からない)
そもそもこんな操作は絶対したくない。これに対してSchemeは静的らしい。つ まりクロージャができた時点でその参照した値になる。
やっぱりUsing Continuations to Implement Thread Management and Communication in Operating Systems.にあった通り、ちょっと、言語系とは違 うかな...。
実際のとこ、そこまでスタック操作した性能の劣化以上の何かがあるようには 思えない。
