10

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?

piokuc
  • 25,594
  • 11
  • 72
  • 102
lonjil
  • 516
  • 4
  • 9
  • 1
    Personally I would prefer if you post questions about real programming problems on Stackoverflow. Plus your question is wrong: 'statistical analysis' - what is that? Also Common Lisp did not 'abandon' FEXPRs. They were out of fashion before CL existed. – Rainer Joswig Aug 20 '13 at 05:32

3 Answers3

6

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.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • Yes, I've read that but it doesn't really explain all the reasons for it. Or was that last thing the only reason? – lonjil Aug 20 '13 at 00:43
  • I don't know anything about fexprs other than what I've read here, @lonji, but that seems like a good enough reason to me. As I understand it, Pitman is saying that including fexprs will have the effect of slowing down code that uses lambdas at run time, because the compiler won't be able to optimize that code. – Mars Aug 20 '13 at 03:59
6

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.

Community
  • 1
  • 1
piokuc
  • 25,594
  • 11
  • 72
  • 102
1

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.

Sylwester
  • 47,942
  • 4
  • 47
  • 79
  • 2
    fexprs are not anonymous macros. Your explanation is wrong in several ways. – Rainer Joswig Aug 20 '13 at 05:22
  • A better way to explain them would be that they're runtime macros. – Zaz Feb 11 '15 at 06:46
  • Yeah, but you would try to expand them where you can. The problem is that you don't expand functions and if you can pass a fexpr as an argument you need to expand them sometimes at runtime. – Sylwester Feb 11 '15 at 12:26