I think you mean to say that Kernel doesn't need to implement macros because they can be built using $vau.

---

Besides that, I think you're overstating its significance.

a) Maxwell's equations don't claim to be 'most fundamental'. They are a concise basis set for a space of problems. They occupy a memetic sweet spot; abstractions both above and below them are more verbose. The metacircular interpreter of Kernel can't compete with McCarthy's version.

b) Any language with fexprs is 'as fundamental' as Kernel. Including LISP 1.

c) In its search for hygiene Kernel eliminates quote. Scheme folks will likely find this a useful tradeoff, while common lisp folks with their backquoted macros will shudder. In kernel you 'create macros' by explicitly consing code.

I concede your point about Maxwell's equations. Their historical significance in particular is the unbelievably rich research that ensued from its implications.

By this metric, Lisp is obviously the analogue in the programming world. It would have been nice though if Lisp had triggered a sudden paradigm shift instead of this painful 50 year burn we're living through.

We're still early in the game. 50 years feels like a long time to an individual human but historically it's just a start.

"The metacircular interpreter of Kernel can't compete with McCarthy's version."

First, it doesn't cover macros, while Kernel subsumes functions and hygienic macros with a single construct. Second, I don't think a toy version of a Kernel metacircular evaluator would be much more complex than the toy McCarthy evaluator.

"Any language with fexprs is 'as fundamental' as Kernel. Including LISP 1."

Only if said language is lexically scoped, and fexprs receive the lexical environment in which they are called as parameter, as in Kernel. Otherwise you'll miss hygiene.

Yeah I'd like to see a toy version of a Kernel metacircular interpreter.

Maybe it's just me, but I don't consider 'better supports hygiene' to imply 'more fundamental'. It doesn't add new capabilities. It merely prevents certain kinds of errors.

(lambda args body) is not the same as ($vau args env body), because the latter doesn't evaluate its operands.

Lambda in Kernel is defined as follows:

  ($define! $lambda
     ($vau (formals . body) env
        (wrap (eval (list* $vau formals #ignore body)
                    env))))

When you say ($lambda (x) x), a new fexpr (that ignores the environment in which it is called, because lambdas don't need it) is constructed -- ($vau (x) #ignore x) -- and then it is wrapped, so that its operands are evaluated.

So,

  (lambda args body)

can be expressed as

  (wrap ($vau args #ignore body))

That beams you right back to the 1960s where FEXPRs were common in Lisp. They died a slow and horrible death at the end of the 70s under the influence of Scheme and Maclisp.

Kernel makes the point that much of the vilification of fexprs was actually caused by dynamic scope. Combining them with lexical scope makes for a surprisingly reasonable language.

That were not the arguments of Pitman.

Hence the use of the word 'actually'.

I recommend shutt's thesis.

Here's the article he's referring to: http://www.nhplace.com/kent/Papers/Special-Forms.html

Here's a discussion on LtU about Pitman-vs-Kernel: http://lambda-the-ultimate.org/node/3640

If you read Pitman's paper, you can read that his critique is not so much about theoretical issues of interaction of dynamic binding, but about practical issues. Pitman was somebody who wrote and used lots of Lisp code which was used by users (for example Macsyma). Dynamic binding was a side issue - practical compilability a much bigger issue.

a) I have read Pitman; please stop insinuating that I haven't.

b) Pitman actually points out that dynamic binding makes compilation of fexprs harder. That was also one of the original selling points of scheme: lexical binding simplifies compiler implementation.

c) Issues of practical compilability are extremely likely to be context-sensitive and hard to generalize from. That some lisp 35 years ago had a hard time compiling some language involving fexprs doesn't help decide if this language here and now can use them.

d) Finally, you're attacking a strawman of your own creation. Pitman didn't focus on dynamic binding, sure. Who said otherwise? That insight was one of Kernel's contributions, that a world where lisps are lexically scoped is actually quite a good fit for fexprs.

Pitman said that compilation of FEXPRS is difficult. Even with lexical binding. Pitman argued for a macro expansion phase. Etc. If you read the original kernel paper it does not even discuss Pitman in more than two sentences. Since Pitman is still alive, he could have even asked him. The kernel paper had a seperate addendum where vague ideas about compilation were discussed.

Pitman was working on large software systems where compilation was the norm and useful.

All the references to lexical scope but one are annotations added decades later. The one early reference said "dynamic scope harder than lexical scope."

In any case, the claim that fexprs make compilation challenging for large software systems is much more nuanced than what you were implying earlier, that Kernel's no different from "the 1960s".

Now that compilation is less challenging thanks to lexical scope, and with computers being so much faster, it's worth considering whether fexprs can be compiled to be fast enough (say to ruby levels for a start). That would still be valuable. Right?

I think it's very superficial to claim that only 'two sentences' of Shutt's thesis were about 'Pitman'. He mentioned the concerns in the abstract[1], for crying out loud. He's addressing the issues throughout even if he isn't constantly paying homage to some sort of Pitman deity.

[1] http://www.wpi.edu/Pubs/ETD/Available/etd-090110-124904