2

今後の R7RS スキーム標準 (スモール ランゲージ)の現在のドラフトを読みましたが、トップレベル バインディングの再定義がエラーにならない条件がわかりません。

定義または設定が可能だと思います！プログラムのトップレベルで 2 回目に導入されたバインディング。しかし、外部ライブラリからインポートされたバインディングについてはどうでしょうか? これらのバインディングを標準でオーバーライドすることは可能ですか?

レポートの 26/27 ページには、次のように書かれています。

プログラムの最上位には、インポート宣言が含まれる場合もあります。ライブラリ宣言では、同じ識別子を異なるバインディングで複数回インポートしたり、define、define-syntax、または set! を使用してインポートされたバインディングを再定義または変更したりすると、エラーになります。ただし、REPL はこれらのアクションを許可する必要があります。

再定義は、インポートされたバインディングのライブラリで発生した場合にのみエラーになるということですか?

コンパイラが+がまだ組み込みの追加を意味するのか、それとも他のユーザー指定のエラーなのかがわからない場合、コンパイラによる最適化を禁止することを理解しています。しかし、この観点からすると、ライブラリ レベルでの再バインドの禁止を制限することは意味がありません。プログラムにインポートされたバインディングに対しても (少なくとも) 意味がある場合です。

PS: これは計画プログラムの環境に関するすべてなので、現在の環境を手に入れることができないため、環境は第一級市民ではないと言っているのは正しいですか? (これにより、コンパイルされたプログラムは、バインディングの選択された名前を忘れることができます。)

4

1 に答える 1

5

一般的な原則として、ライブラリで宣言されたバインディングは、同じライブラリでのみ移植可能に変更できます。ライブラリのバインディングがプログラム（または別のライブラリ）にインポートされている場合、そこで変更することはできません。したがって、プログラムがインポートする場合(scheme base)、識別子+は常に標準の追加ルーチンを参照しlambda, let, let*ます（もちろん、ローカルでシャドウイングされている領域、またはあなたが持っているものを除く）。

REPLで、またはREPLによって実行されているスクリプトでは、この制限は適用されません。さらに、実装は制限を解除することによって標準言語を拡張することができます。

現在のグローバル環境に最も近いものは、の結果です(interaction-environment)。これは、REPLの可変環境（存在する場合）を表します。REPLが使用されていないか存在しない場合は、environment現在のインポートのセットに対応する引数を呼び出すことにより、現在の、しかし不変の環境をシミュレートできます。R7RSは、その前身と同様に、字句環境の表現を持っていません。

于 2012-11-03T18:00:48.650 に答える