Fexpr

In strict original usage, a FEXPR is therefore a user-defined function whose operands are passed unevaluated.It is suggested that, in the design of future Lisp dialects, serious consideration should be given to the proposition that FEXPR's should be omitted from the language altogether.Starting with Brian Smith's 3-Lisp in 1982, several experimental Lisp dialects have been devised to explore the limits of computational reflection.[11] In 1998, Mitchell Wand showed that adding a fexpr device to lambda calculus — a device that suppresses rewriting of operands — produces a formal system with a trivial equational theory, rendering it impossible to make source-to-source optimizations without a whole-program analysis.[10] In 2007, John N. Shutt proposed an extension of lambda calculus that would model fexprs without suppressing rewriting of operands, avoiding Wand's result.
association listfirst-class functionSchemeenvironmentstatically scopedLisp 1.5MacLispInterlispConference on Lisp and Functional ProgrammingKent Pitmanstatic analysisCommon LispnewLISPPicolispBrian Smithcomputational reflectionMitchell Wandlambda calculusformal systemtheorywhole-program analysisECL programming languagesyntax treepromiseslazy evaluationMcCarthy, J.Fox, P.Hodes, L.Luckham, D.Park, D.Russell, S.BostonMassachusettsM.I.T. Computation Center