4 ms·

Thanks for the correction and info. I have to retract my claim about the reason those languages use FEXPRs, but I'm not convinced they're good reasons. There a

Thanks for the correction and info. I have to retract my claim about the reason those languages use FEXPRs, but I'm not convinced they're good reasons. There are, however, very good reasons why the FEXPR approach has been abandoned by other languages, as the Pitman article points out. There are certainly better ways to achieve pretty much anything you might want FEXPR-style source code access for. Aside from the Lisp world, there are things like Template Haskell, Rust macros, Ocaml's Camlp4/5, etc. But you don't even need a macro-like system to implement most of the kinds of features in question here. For example, here's "A Purely Functional Computer Algebra System Embedded in Haskell": https://arxiv.org/abs/1807.01456 https://arxiv.org/abs/1807.01456 It exploits the type system, lazy evaluation, purity, and property-based testing to implement a computer algebra system without needing to accept all the compromises involved in having programs manipulate their own source code.

kazinator 4y ago
I'm thoroughly convinced that fexprs are a bad idea and so, good riddance. Our Lisp hacking predecessors did us a huge favor by figuring this out and documenting it. Fexprs are hostile toward compiling. Specifically, True Scotsman's ahead-of-time compiling where we take an entire file or set of files and turn them into compiled equivalents, whereby we obtain: 1. Useful diagnostics without running the code. 2. Deliverables which load and execute faster, and don't require any code processing at run time (unless we choose that as part of application logic). 3. Resistance to reverse engineering, so we get paid. :) Even a macro expander in front of an interpreter can provide error checking, such as finding unbound variables, reporting about misused special forms, and even things like functions being called with wrong numbers of arguments. Macros themselves can be well written and provide decent error checking. So could fexprs, but fexprs have to be called. You can't code walk fexprs because you don't know which parts of the argument material of a fexpr contains more fexprs. It is counterproductive to lose the ability to completely code-walk a program, just to gain the ability to perpetrate trompe d'oeil metaprogramming: the software engineering equivalent of having a hand reach out of the picture, holding a pencil which draws the picture frame.

kazinator 4y ago

I'm thoroughly convinced that fexprs are a bad idea and so, good riddance. Our Lisp hacking predecessors did us a huge favor by figuring this out and documenting it. Fexprs are hostile toward compiling. Specifically, True Scotsman's ahead-of-time compiling where we take an entire file or set of files and turn them into compiled equivalents, whereby we obtain: 1. Useful diagnostics without running the code. 2. Deliverables which load and execute faster, and don't require any code processing at run time (unless we choose that as part of application logic). 3. Resistance to reverse engineering, so we get paid. :) Even a macro expander in front of an interpreter can provide error checking, such as finding unbound variables, reporting about misused special forms, and even things like functions being called with wrong numbers of arguments. Macros themselves can be well written and provide decent error checking. So could fexprs, but fexprs have to be called. You can't code walk fexprs because you don't know which parts of the argument material of a fexpr contains more fexprs. It is counterproductive to lose the ability to completely code-walk a program, just to gain the ability to perpetrate trompe d'oeil metaprogramming: the software engineering equivalent of having a hand reach out of the picture, holding a pencil which draws the picture frame.