プログラミング言語 Scheme に関する R7RS レポートでは、Scheme システムで Scheme コードを実行する 2 つの方法について説明しています。
1) レポートのセクション 5.1 で説明されているように、スキーム システムはプログラムを実行できます。
2) スキーム システムは、Scheme コードが対話的に解釈される read-eval-print-loop を提供できます。
私の質問は、Scheme コードを実行するこれら 2 つの方法が、R7RS レポートに含まれている内容を使用して、Scheme システム内にどのように反映されるかということです。
eval実行中のSchemeシステム内でSchemeコードを実行するevalライブラリプロシージャがあり、eval私が探しているもののように見えます。
ただし、プラグインできる唯一の保証された変更可能な環境は、 repl ライブラリ プロシージャevalによって返される環境です。interaction-environmentただし、これでは、REPL (上記のポイント 2) を確実にシミュレートすることはできません。これは、REPL がインポート フォームを許可するevalためです。
また、別の理由により、Scheme プログラム全体を ing するために対話環境を使用することもできませんeval。通常は空ではありません。特に、(scheme base).
1）実行中のSchemeシステム内で実現するには、evalライブラリ手順environmentが有望に見えます（実行中のプログラムの一部である）ライブラリを事前にインポートできるからです。ただし、環境は不変であるためdefine、環境内で s を評価することはできません。解決策は、実行するプログラムの本体をlambdaフォームでラップして、defineローカル変数を定義することです。ただし、これも機能しません。lambdaフォーム内では、すべての定義が本体の先頭に来る必要があり (これは、Scheme プログラムのトップレベルには当てはまりません)、lambdaフォーム ライブラリ バインディング内では、レキシカルに上書きできます。トップレベルのバインディングでは不可能です。
Scheme はチューリング完全であるため、実行中の Scheme システム内で Scheme システムをシミュレートすることはもちろん可能ですが、eval手順を使用するだけでそれが可能かどうか疑問に思っています。私が興味を持った理由の 1 つは、eval(JIT コンパイラ バックエンドなどによって) 最適化される可能性があるため、この手順を使用すると、ネイティブに近い速度が得られる可能性があることです (単純なインタープリターを手動で作成する場合と比較して)。