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?
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.