Many LISPs had FEXPRs but they were not included in CL.
I read that this was because FEXRPs don't work well with static analysis.
Can someone explain this?
问题:
回答1:
From the Wikipedia article on FEXPRs:
At the 1980 Conference on Lisp and Functional Programming, Kent Pitman presented a paper "Special Forms in Lisp" in which he discussed the advantages and disadvantages of macros and fexprs, and ultimately condemned fexprs. His central objection was that, in a Lisp dialect that allows fexprs, static analysis cannot determine generally whether an operator represents an ordinary function or a fexpr — therefore, static analysis cannot determine whether or not the operands will be evaluated. In particular, the compiler cannot tell whether a subexpression can be safely optimized, since the subexpression might be treated as unevaluated data at run-time.
回答2:
Kent Pitman called for abandoning fexpr because it seemed to be impossible to compile it.
For an in-depth discussion of fexpr see John N. Shutt's PhD dissertation Fexprs as the basis of Lisp function application or $vau : the ultimate abstraction.
回答3:
FEXPR
are more like DEFUN
than DEFMACRO
as they become first class objects. This seems to be difficult for the compiler, since it cannot know if something is a functions or a macro at compile time leaving perhaps some macros not expanded at compile time. You can read the paper here with comments.
After reading it I'm uncertain if his conclusions are still true given our compilers are better at doing advanced constant folding and other optimizations. Anyway, higher order macros are not that useful as higher order functions so we won't miss them much.
Paul Grahams Arc has anonymous macros and kernel has them too so it's not completely gone, but I feel that was just for convenience. Try map
with it and you'll see how useful it isn't.