The fact that fexprs are not easily accessible in the major lisp and scheme dialects is quite unfortunate because it makes it difficult to express certain proce

The fact that fexprs are not easily accessible in the major lisp and scheme dialects is quite unfortunate because it makes it difficult to express certain process structures. Like with all advanced language features they would have to be used carefully, but from reading Shutt's discussion of fexprs and interpreters it seems that adding them would move a language to nearly complete expressiveness. There are invariants that you would like to be able to express as part of a specification for a process where the exact implementation is unknown at compile time. Further, the exact choice of implementation may depend on the runtime results of a previous step, requiring nested fexprs. There are many processes that are more naturally expressed in this way. Consider for example trying to specify a function that transforms an environment from one where a package is not installed to one where it is installed. There are a huge number of ways that this might be implemented, and an fexpr can serve as a specification for the information that must be provided so that it can be carried out automatically, e.g. rather than specifying the name of the package, the name of the package manager, the name of the source repository, a dependency list, etc. that can all be ignored and instead a single function implementing install-package can be provided. Some of the simpler examples can be implemented using only first class functions and closures, however as soon as there are expressions where the evaluation of the arguments need to be deferred then you need fexprs.