3 ms·

There are some Lisp communities which value syntactic extensibility more than low-level performance. For example when using FEXPRs, which are functions which ha

by lispm 4y ago

There are some Lisp communities which value syntactic extensibility more than low-level performance. For example when using FEXPRs, which are functions which have access to their source and where the function decides which arguments to evaluate. You'll find that in R, Picolisp, Standard Lisp and a few others. Most other Lisp communities have settled on always strict evaluation and compilable macros as syntactic extensions.

antonvs 4y ago
FEXPRs haven’t been relevant in mainstream Lisp since the 1980s. See Kent Pitman’s 1980 article describing the problems with them: https://www.nhplace.com/kent/Papers/Special-Forms.htmL https://www.nhplace.com/kent/Papers/Special-Forms.htmL The languages you mention probably use them mainly because they’re easy to implement in the language implementation, which has nothing to do with what the community values, except in a post-hoc sense when the community tries to justify to itself why it’s using such an inherently intractable feature.
- 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

FEXPRs haven’t been relevant in mainstream Lisp since the 1980s. See Kent Pitman’s 1980 article describing the problems with them: https://www.nhplace.com/kent/Papers/Special-Forms.htmL https://www.nhplace.com/kent/Papers/Special-Forms.htmL The languages you mention probably use them mainly because they’re easy to implement in the language implementation, which has nothing to do with what the community values, except in a post-hoc sense when the community tries to justify to itself why it’s using such an inherently intractable feature.

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.