3 ms·

Usually the arguments are a) it provides runtime access to the source (which for example is useful in R), b) runtime introspection is easier to understand (for

by lispm 4y ago

Usually the arguments are a) it provides runtime access to the source (which for example is useful in R), b) runtime introspection is easier to understand (for the proponents) & less complex than macros and that macros are too static (they want more flexibility at runtime). For example authors of the REDUCE computer algebra system ( https://reduce-algebra.sourceforge.io/ https://reduce-algebra.sourceforge.io/ ) disliked Common Lisp for the lack of FEXPRs and that's why they stayed away from it. There were lots of discussions at the time when Common Lisp was introduced. > The languages you mention probably No, see above. Example: https://picolisp.com/wiki/?pros-and-cons https://picolisp.com/wiki/?pros-and-cons

antonvs 4y ago
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.

by lispm 4y ago

antonvs 4y ago

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.