私はそれをよりよく理解するためにDLRで遊んでいます。私はまだそのすべての概念とその用語に完全に精通しているわけではないので、私の質問に用語または概念上の誤りがあったことをお詫びします。
基本的に、私が理解している方法は、式ツリーでオブジェクトを渡しますが、オブジェクトの動的機能を他の DLR 対応言語に公開するためにバインダーを使用するということです。したがって、式ツリー (With Expression.Add) で直接追加を行う代わりに、必要なときにいつでも呼び出しサイトによって呼び出されて追加を行うバインダーを作成します。
ただし、オブジェクトを渡すため、加算操作の最後に (たとえば、オペランドが 2 つの Int32 値である場合)、結果の Int32 をオブジェクトにボックス化する必要があります。サイトは期待しています。この一定のボックス化/ボックス化解除がランタイムのパフォーマンスに多少影響するのではないかと少し心配しています。
これは本当に（すべてのボックス化/ボックス化解除で）動作するはずの方法ですか、それとも何か不足していますか？
バインダーに関する限り、カスタム バインダーを実装することもできます。そのカスタム バインダーは、非オブジェクト型を返すか、他の特定の最適化を行うことができます。IronPython では、DLR 外部層 ComboBinder と ComboActionRewriter を使用して条件を最適化します。たとえば、「if ab:」は、ab と bool への変換の両方を行う ComboBinder に変換できます。ab がボックス化されていない bool になる場合、ボックス化とボックス化解除を回避します。このような最適化をさらに実験する予定です。
動的型付け言語では、静的型付け変数の識別と最適化はドメイン固有の最適化です。特定の動的言語 X の実装内では、ボックス化されていないローカル変数を生成されたコードに保持できますが、動的に型指定された API を公開するとすぐに、静的型付け (動的言語の性質そのもの) を保証する方法はありません。
ボクシングを避けるには、全体を通して静的型を証明できるコードの断片を特定し、Linq.ExpressionsまたはILGenerator.