When you get first-class fexprs, you pay for it in performance. They're nearly impossible to compile, and even interpreting them efficiently is a challenge.
Read Sutt's paper, then decide if he didn't fix the performance problem. I haven't gotten around to it yet, so I'm not sure, but apparently $vau-calculus has some interesting properties.
I read Shutt's thesis back when he first published it. I'll admit I'm due for another reading. The vau calculus is indeed very interesting, but there are fundamental reasons why fexprs can't be implemented efficiently (at least, not on commodity hardware). Of course, depending on your use-case, they might be fast enough, which is what really matters in the end. (Shutt's homepage offers the "official" interpreter that goes along with the thesis, and even he admits that it's painfully slow).
So is the problem with fexprs the fact that subexpr elimination can't happen because you don't know what will be a fexpr at optimization time? Or is it something else? Because if it's just that, then why can't a fexpr just be an ordinary function whose canonical name is actually a macro that `quote`s its arguments? I'm assuming I'm missing something, because somebody must have tried that by now.
Or you could just `quote` the call yourself, like TCLers do.
> So is the problem with fexprs the fact that subexpr elimination can't happen because you don't know what will be a fexpr at optimization time?
That's part of it. But the bigger issue is, I think, that you can't even generally compile[0] the arguments before runtime, because you don't necessarily know what expressions they'll be by the time they get evaluated.
> Because if it's just that, then why can't a fexpr just be an ordinary function whose canonical name is actually a macro that `quote`s its arguments?
That's exactly what they are, along with the environment at the call site. Then, when (and if) you need the arguments to be evaluated, you do it explicitly with a call to `eval`. But keep in mind that the fexpr body is free to modify those arguments as data before evaluating them.
> Or you could just `quote` the call yourself, like TCLers do.
Tcl is similarly a very difficult language to compile and/or optimize.
[0]: I mean ahead-of-time compilation here. I don't see any reason why a JIT compiler couldn't be effective.
Okay. So this is essentially the "eval is slow" problem all over again. If that's the problem, then it's endemic to all Lisps. Fexprs just encourage that style of programming.
According the summary of the Wand paper, though, another problem is that optimizations can't happen without full-program analysis. And now the question becomes, if fexprs can be trivially implemented in lisp using macros, or just hand-quoting args, then why don't non-fexpr lisps have this issue? And if they do, why don't we just add fexprs, and first class environments, and eliminate macros entirely?
