fexprs that aren’t first class are just macros; both the problems and the power of fexprs come because they are values.

I agree that the system Dave describes would be more amenable to redefinition; I also think it’s probably a bad idea. But that’s mostly because programming models that seem convenient but can’t be given a meaning are a bad idea.

If we can change a running program by redefining a macro, and if that at some point causes previously macroexpanded syntax to be re-macroexpanded, the program must have kept that syntax around the whole time. (We can tell it kept the syntax around by replacing the macro with a macro that displays a quoted form of the syntax, assuming such a change is consistent with the interface of the macro.) This means pretty much the only program behaviors that are equal up to observation are the ones that are expressed with equal syntax. In other words, the semantics has a trivial equational theory. When you talk about a language construct that “can’t be given a meaning,” I think hot reloading is already that kind of language construct.

Trivializing the equational theory doesn’t depend on first-class macros, just macros that can vary at run time (or so I believe, since I bet my reasoning above could have some creative holes poked in it). I think the essential difficulties of this problem domain are similar enough to those of fexprs that I expect some people (other than myself) to carry out an investigation of one of them under the name of the other. That’s the kind of connection I mean to offer by saying fexprs “come up in this kind of conversation,” and I don’t mean to imply that everyone should use fexprs in their terminology or that this topic is the only thing fexprs are about.