I love Lisp (I'm an Emacs user and often write in Racket for personal projects) but the one thing I never understood about the Lisp community is the emphasis placed on metacircular evaluators.

I sure find them beautiful and all, but why do they take center stage so often? Beside the aesthetics and instructional value, I don't get the appeal. Also I feel that a bunch of the heavy lifting behind metacircular evaluators is actually done by the Polish notation syntax as well as the actual implementation, and these concepts don't get nearly as much love.

Any Lisper who can illuminate me?

▲ Quitschquat 5 days ago | parent | next [-]

Long time lisper. It just doesn’t feel right unless your language can compile your language. It’s like wearing someone else’s underwear.

▲

fuzztester 5 days ago | parent [-]

or interpret

▲

Y_Y 4 days ago | parent [-]

Agreed, I hate interpreting other people's underwear.

	▲	bifftastic 4 days ago \| parent [-]
		Username checks out

▲ rootnod3 5 days ago | parent | prev [-]

The metacircular evaluator shows how code is data and data is code.

And in a way it’s like Maxwell’s equations. A simple proof of computation that also somehow implements a very neat language.

▲ Y_Y 4 days ago | parent [-]

But of course you must close the loop by representing Maxwell's equations electromagnetically.

I know this is a classic analogy, but now you've got me wondering, originally Maxwell wrote a messy pile of equations of scalrs, later someone (Gibbs?) gave them the familiar vector calculus form. Nowadays we have marvellously general and terse form, like (using the differential of the Hodge dual in naturalised units),

  d star(F) = J

My question is, when are we going to get some super-compact unified representation of `eval`?

	▲	rootnod3 4 days ago \| parent \| next [-]
		It is a bit similar. The first versions in Lisp 1.0 and the Lisp 1.5 paper were working, but not fully refined. SICP and others later presented it a bit more refined in my opinion. There's also version for the metacirculator interpreter written in full on M-expr, but they kinda break the spirit of things. I think the version of eval that we have is already pretty terse for what it is. You could maybe code-golf it into something smaller, or you could code-golf it into something fully immutable. My only gripe is that they all rely on an already existing reader that parses the expressions for you and represents them. Which is exactly what the book is about. Finding a small enough interpretation that does ALL of it would be a dream, but I doubt it could be anywhere near as concise as the (modern) Maxwell equations.
	▲	tromp 4 days ago \| parent \| prev \| next [-]
		It's hard to get a super compact eval for LISP with its many primitives. It's somewhat easier for the lambda calculus which inspired LISP, with obnly the 3 primitives of variable, abstraction, and application. In the binary lambda calculus this allows for a self-interpreter `(λ 1 1) (λ λ λ 1 (λ λ λ λ 3 (λ 5 (3 (λ 2 (3 (λ λ 3 (λ 1 2 3))) (4 (λ 4 (λ 3 1 (2 1)))))) (1 (2 (λ 1 2)) (λ 4 (λ 4 (λ 2 (1 4))) 5)))) (3 3) 2)` that tokenizes and parses a closed lambda term from a raw binary input stream and passes the term and the remainder stream to a given continuation [1]. [1] https://tromp.github.io/cl/cl.html
	▲	kingaillas 4 days ago \| parent \| prev [-]
		>later someone (Gibbs?) gave them the familiar vector calculus form. It was Oliver Heaviside (https://en.wikipedia.org/wiki/Oliver_Heaviside) that rewrote Maxwell's original equations (20 of them in differential form) into the notation used today (4 of them in vector calculus form). Here's a nice comparison: https://ddcolrs.wordpress.com/2018/01/17/maxwells-equations-...