3 ms·

So what's the difference between fexprs and macros? Can you give an example that illustrates it?

rileyphone 4y ago
Consider this answer from lispm as to what fexprs can do that macros cannot, namely being first-class objects in the language that can be stored and passed as values, just as a number or a function can be. https://stackoverflow.com/questions/13393673/how-do-you-store-a-macro-in-a-variable-in-common-lisp-sbcl https://stackoverflow.com/questions/13393673/how-do-you-stor...
- Sniffnoy 4y ago
  I see, thanks! Is that the only additional capability or is there more?
  - rileyphone 4y ago
    They have the advantage of making macro writing a good deal simpler, by providing a higher-level control over metaprogramming. The effect is almost like CLOS-style classes in comparison to C++ classes - a more complete metaphor (metaprogramming/OOP) is more difficult to implement and optimize, but makes up for in improved programmability. Of course this is all highly subjective. Perhaps fexpr was just a weird language construct that introduced more problems than it solved. I think it is an unexplored avenue that was brought to light again by Kernel. You really need fexprs to get a true programmable programming language in the sense their are no exceptions. Maybe the cost can become reasonable.
    - Sniffnoy 4y ago
      I mean I'm asking about concrete differences in how they fundamentally work, since I'm not familiar with fexprs in the first place, and (as someone who doesn't use Lisp) not very familiar with macros either. I'm not asking about larger consequences like the sort you describe in this answer.
      - rileyphone 4y ago
        In that case, I would recommend reading this post. Shutt explains it much better than I can. https://fexpr.blogspot.com/2011/04/fexpr.html https://fexpr.blogspot.com/2011/04/fexpr.html
        Sniffnoy 4y ago
        That post doesn't mention macros at all, so it does not seem to contain the macro-vs-fexpr contrast I'm looking for.
alexisread 4y ago
I think the main difference is that macros statically evaluate their inputs ie. at compile-time. fexprs can selectively eval their inputs at runtime ie. dynamically. This has given the impression of slowness and difficulty to grok with fexprs, as dynamic eval foregoes certain optimisations, and scoping the fexpr bindings is hard (variable capture is a problem). https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unrestricted/jshutt.pdf https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unr... is a good paper on this stuff (see p41/42 for a discussion). Another version of fexprs/vau is open composition https://www.piumarta.com/freeco11/freeco11-piumarta-oecm.pdf https://www.piumarta.com/freeco11/freeco11-piumarta-oecm.pdf I guess the main issue is handling dynamic binding cleanly. Koka https://koka-lang.github.io/koka/doc/book.html#why-handlers https://koka-lang.github.io/koka/doc/book.html#why-handlers handles this well with static (HM) type inferrence. Shen and Maude (https://shenlanguage.org/TBOS/tbos_255.html https://shenlanguage.org/TBOS/tbos_255.html, https://maude.lcc.uma.es/maude321-manual-html/maude-manual.html https://maude.lcc.uma.es/maude321-manual-html/maude-manual.h...) are the only languages that I know that can do dynamic type checking, and thus a full handling of dynamic binding, the Shen calculus syntax is a bit clunky though.
- bsder 4y ago
  > This has given the impression of slowness and difficulty to grok with fexprs, as dynamic eval foregoes certain optimisations, and scoping the fexpr bindings is hard (variable capture is a problem). And yet, Javascript, possibly the most widespread language on the planet, does exactly this and has been optimized for speed to hell and back several times. The problem wasn't unsolvable. The problem was that there wasn't enough money behind solving it.
  - lispm 4y ago
    JavaScript has Fexprs?
    - bsder 4y ago
      JavaScript has highly dynamic eval with lots of scoping issues very similar to the issues that everybody thought were dealbreakers with fexprs. And, yet, somehow a lot of very clever people made Javascript one of the fastest languages around.

Consider this answer from lispm as to what fexprs can do that macros cannot, namely being first-class objects in the language that can be stored and passed as values, just as a number or a function can be. https://stackoverflow.com/questions/13393673/how-do-you-store-a-macro-in-a-variable-in-common-lisp-sbcl https://stackoverflow.com/questions/13393673/how-do-you-stor...

Sniffnoy 4y ago
I see, thanks! Is that the only additional capability or is there more?
- rileyphone 4y ago
  They have the advantage of making macro writing a good deal simpler, by providing a higher-level control over metaprogramming. The effect is almost like CLOS-style classes in comparison to C++ classes - a more complete metaphor (metaprogramming/OOP) is more difficult to implement and optimize, but makes up for in improved programmability. Of course this is all highly subjective. Perhaps fexpr was just a weird language construct that introduced more problems than it solved. I think it is an unexplored avenue that was brought to light again by Kernel. You really need fexprs to get a true programmable programming language in the sense their are no exceptions. Maybe the cost can become reasonable.
  - Sniffnoy 4y ago
    I mean I'm asking about concrete differences in how they fundamentally work, since I'm not familiar with fexprs in the first place, and (as someone who doesn't use Lisp) not very familiar with macros either. I'm not asking about larger consequences like the sort you describe in this answer.
    - rileyphone 4y ago
      In that case, I would recommend reading this post. Shutt explains it much better than I can. https://fexpr.blogspot.com/2011/04/fexpr.html https://fexpr.blogspot.com/2011/04/fexpr.html
      - Sniffnoy 4y ago
        That post doesn't mention macros at all, so it does not seem to contain the macro-vs-fexpr contrast I'm looking for.

alexisread 4y ago

I think the main difference is that macros statically evaluate their inputs ie. at compile-time. fexprs can selectively eval their inputs at runtime ie. dynamically. This has given the impression of slowness and difficulty to grok with fexprs, as dynamic eval foregoes certain optimisations, and scoping the fexpr bindings is hard (variable capture is a problem). https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unrestricted/jshutt.pdf https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unr... is a good paper on this stuff (see p41/42 for a discussion). Another version of fexprs/vau is open composition https://www.piumarta.com/freeco11/freeco11-piumarta-oecm.pdf https://www.piumarta.com/freeco11/freeco11-piumarta-oecm.pdf I guess the main issue is handling dynamic binding cleanly. Koka https://koka-lang.github.io/koka/doc/book.html#why-handlers https://koka-lang.github.io/koka/doc/book.html#why-handlers handles this well with static (HM) type inferrence. Shen and Maude (https://shenlanguage.org/TBOS/tbos_255.html https://shenlanguage.org/TBOS/tbos_255.html, https://maude.lcc.uma.es/maude321-manual-html/maude-manual.html https://maude.lcc.uma.es/maude321-manual-html/maude-manual.h...) are the only languages that I know that can do dynamic type checking, and thus a full handling of dynamic binding, the Shen calculus syntax is a bit clunky though.

bsder 4y ago
> This has given the impression of slowness and difficulty to grok with fexprs, as dynamic eval foregoes certain optimisations, and scoping the fexpr bindings is hard (variable capture is a problem). And yet, Javascript, possibly the most widespread language on the planet, does exactly this and has been optimized for speed to hell and back several times. The problem wasn't unsolvable. The problem was that there wasn't enough money behind solving it.
- lispm 4y ago
  JavaScript has Fexprs?
  - bsder 4y ago
    JavaScript has highly dynamic eval with lots of scoping issues very similar to the issues that everybody thought were dealbreakers with fexprs. And, yet, somehow a lot of very clever people made Javascript one of the fastest languages around.