June 26, 2026
Eval of Duty
FEXPRs vs. vtable: how LispE interpreter works
This ‘best of both worlds’ coding idea sparked eye-rolls, intrigue, and one brutal reality check
TLDR: LispE’s big pitch is simple: keep code flexible while still making it fast by turning each instruction into an object that runs itself. Commenters were split between curiosity, corporate surprise over Naver’s involvement, and a savage camp saying Lisp solved this years ago already.
A brainy write-up about how LispE works somehow turned into a very online mini-drama about whether this is a genius workaround or just old wine in a very nerdy bottle. The big idea, in plain English: instead of choosing between code that stays flexible and code that runs super efficiently, LispE tries to do both. It keeps the code’s tree-like structure alive while turning each instruction into its own little C++ object that knows how to run itself. To fans, that sounds like a clever cheat code. To skeptics, it sounds suspiciously like a fancy rebrand.
And the comments? Classic internet. One reader, Joker_vD, practically responded by quoting the whole “miracle” pitch back at the article, which reads like a raised eyebrow in text form. Another commenter, sourdecor, swerved away from the theory and fixated on the corporate subplot: wait, this unusual Lisp project is being developed by Naver, the Korean tech giant? That surprise alone gave the thread a little “plot twist” energy.
Then came the blunt hit from rjsw, who delivered the coldest take in the room: Lisp already has good native compilers, just use one of those. Ouch. That one-liner basically split the vibe in two: is LispE an exciting fresh path, or an elaborate answer to a problem some people think was solved ages ago? There weren’t many memes, but the humor came from the contrast itself: one side shouting “miracle!”, the other replying, essentially, “buddy, we have that at home.”
Key Points
- •The article describes LispE as an interpreter that executes compiled object representations of language instructions rather than choosing strictly between interpretation and compilation.
- •In LispE, each instruction is implemented as a class derived from a common base class, Element, and each class defines its own eval method.
- •The article proposes an equivalence between function application and object evaluation: `f(a₁,..,aₙ)` is represented as constructing `F(a₁,..,aₙ)` and calling `eval()`.
- •It states that this equivalence holds only if instruction objects are immutable, with data treated as the zero-arity case whose eval returns the object itself.
- •The article contrasts LispE’s design with historical Lisp FEXPRs, arguing that FEXPRs hinder static analysis and optimization, as discussed by Kent Pitman in 1980.