フェックス

Lispプログラミング言語では、 fexprはオペランドが評価されずに渡される関数です。fexpr が呼び出されると、fexpr の本体のみが評価され、fexpr によって明示的に開始されない限り、他の評価は行われません。対照的に、通常の Lisp 関数が呼び出されると、オペランドは自動的に評価され、これらの評価の結果のみが関数に提供されます。また、(従来の) Lisp マクロが呼び出されると、オペランドは評価されずに渡されますが、マクロ関数が返す結果は自動的に評価されます。

初期のLispでは、環境は各シンボルを直接値にマッピングするのではなく、連想リストにマッピングしていました。 ^{[1]これらのリストの標準キーには、シンボルが引数として出現したときに検索されるデータ値を格納するために使用される2つのキー（} APVALとAPVAL1）と、シンボルが演算子として出現したときに検索される関数を格納するために使用される4つのキーがありました。ファンクションキーのうち、SUBR はコンパイルされた通常の関数を示し、そのオペランドは評価されて渡されました。 FSUBR はコンパイルされた特殊フォームを示し、そのオペランドは評価されずに渡されました。 EXPR はユーザー定義の通常の関数を示し、FEXPR はユーザー定義の特殊フォームを示しました。 FEXPR と EXPR の唯一の違いは、オペランドが自動的に評価されるかどうかでした。

厳密に言えば、FEXPR はオペランドが評価されずに渡されるユーザー定義関数です。しかし、後の使用法では、関数がプリミティブかユーザー定義かに関係なく、オペランドが評価されずに渡されるあらゆるファーストクラス関数をfexpr と呼ぶことがあります。^[2]

fexpr がどのように動作するかを簡単に示すために、 Schemeに似た Kernel プログラミング言語で記述された fexpr 定義を示します。(Kernel の慣例により、fexpr の名前は常に$で始まります。)

( $define! $f ( $vau ( x y z ) e ( $if ( >=? ( eval x e ) 0 ) ( eval y e ) ( eval z e )))) 
       
           
             
             

この定義は、 3 つのオペランドを取る$fという fexpr を提供します。fexpr が呼び出されると、fexpr が定義された静的環境を拡張することによってローカル環境が作成されます。次に、ローカル バインディングが作成されます。シンボルx、y、zはfexpr 呼び出しの 3 つのオペランドにバインドされ、シンボルe はfexpr が呼び出される動的環境にバインドされます。次に、fexpr の本体($if  ... )がこのローカル環境で評価され、その評価の結果が fexpr 呼び出しの結果になります。最終的な効果は、最初のオペランドが動的環境で評価され、その評価結果が負でないかどうかに応じて、2 番目または 3 番目のオペランドが評価され、その結果が返されることです。もう一方のオペランド (3 番目または 2 番目) は評価されません。

この例は静的スコープです。つまり、ローカル環境は静的環境の拡張です。1980年頃までは、fexprをサポートするLisp言語は主に動的スコープでした。つまり、ローカル環境は静的環境ではなく動的環境の拡張でした。^[3]ただし、ローカルパラメータ名をキャプチャしないようにするために、動的環境にローカル名を指定する必要がある場合もあります。^[4]

fexprのサポートは、Lispが複数の言語に分裂する前の最後の実質的に標準的なLisp方言であるLisp 1.5でも継続されました。 ^[5] 1970年代には、2つの主要なLisp言語^[6]であるMacLispとInterlispは両方ともfexprをサポートしていました。^[7]

1980 年のLisp と関数型プログラミングに関する会議で、ケント ピットマンは「Lisp の特殊形式」という論文を発表し、マクロと fexpr の利点と欠点を論じ、最終的に fexpr を非難しました。彼の主な反論は、fexpr を許可する Lisp 方言では、静的解析では演算子が通常の関数を表すのか fexpr を表すのかを一般的には判断できないため、静的解析ではオペランドが評価されるかどうかを判断できないというものでした。特に、部分式は実行時に未評価データとして扱われる可能性があるため、コンパイラは部分式を安全に最適化できるかどうかを判断できません。

MACROは特別なフォーム定義を指定するための適切なメカニズムを提供しますが、FEXPRはそうではありません。将来の Lisp 方言の設計では、 FEXPRを言語から完全に削除するという命題を真剣に検討する必要があることが示唆されています。 ^[8]

MacLisp と Interlisp の衰退以来、1993 年までに優勢に立った 2 つの Lisp 言語^[9] — SchemeとCommon Lisp — は fexprs をサポートしていません。newLISPはfexprs をサポートしていますが、これを「マクロ」と呼んでいます。Picolisp では、すべての組み込み関数は fsubrs ですが、Lisp レベルの関数は exprs、fexprs、lexprs、またはそれらの混合です。

1982年のブライアン・スミスの3-Lispに始まり、計算リフレクションの限界を探るためにいくつかの実験的なLisp方言が考案された。リフレクションをサポートするために、これらのLispは、呼び出しに関連するさまざまなデータ構造を具体化できる手続きをサポートしている。これには、呼び出しの未評価のオペランドも含まれ、これらの手続きはfexprになる。1990年代後半までに、fexprは主に計算リフレクションに関連付けられるようになった。^[10]

fexpr に関する理論的成果はいくつか得られている。1993 年、ジョン・C・ミッチェルは、ソース式が形式的に抽象化できないプログラミング言語の例として、fexpr を使用した Lisp を使用した (ソース式の具体的な構文は、fexpr のオペランドであるコンテキストによって常に抽出できるため)。^[11] 1998 年、ミッチェル・ワンドは、ラムダ計算に fexpr デバイス(オペランドの書き換えを抑制するデバイス)を追加すると、自明な方程式理論を持つ形式システムが生成され、プログラム全体の分析なしではソース間の最適化を行うことが不可能になることを示した。^[10] 2007 年、ジョン・N・シャットは、オペランドの書き換えを抑制せずに fexpr をモデル化するラムダ計算の拡張を提案し、ワンドの結果を回避した。^[12]

• イスイム
• ドウィム

次の言語は fexprs またはそれに近いものを実装しています。

• ECLプログラミング言語は、引数式の構文ツリーがパラメーターにバインドされることUNEVALを指定するパラメーター タイプ (「bind-class」) を提供します。
• ioメソッド (ブロック) はイントロスペクションを使用でき、 を使用してcall呼び出し全体を参照し、それを操作できます。io の call スロットと self スロットを参照してください。
• カーネルは、Schemeで関数を作成する$vau方法と同様に、を使用して fexpr を作成します。lambda
• newLISP はfexpr を定義するために使用しますdefine-macro。セクション「Fexpr マクロと書き換えマクロ」を参照してください。
• PicoLispでは、呼び出されたときに評価されていない引数式のリストにバインドされる(de foo X ...)fexpr を定義します。PicoLisp での評価を参照してください。fooX
• Rパラメータは通常、Promiseにバインドされ(遅延評価が行われます)、substitute(param)パラメータを呼び出すと引数式が生成されます。R の置換を参照してください。
• REBOLでは、評価されない引数式は、呼び出し元によってブロック (角括弧) で囲む必要があります。つまり、引数の評価を妨げる呼び出し先を定義することはできません。例については、この記事を参照してください。この意味では、REBOL には fexpr はなく、その使用法の一部をエミュレートするのが簡単になっているだけです。真の fexpr を持つ言語では、fexpr 呼び出しは通常の関数呼び出しのように見えます。一方、REBOL では、引数が評価されない呼び出しは、常に通常の関数呼び出しとは異なって見えます。