Currently + is implemented as a special form. You could translate + to operator.add, treat it like a function, and obtain better generality. Also, lambda is not implemented. (The only functions are global ones using 'set'). Lambda is, in some sense, the essence of a Lisp; it seems like a reach to call this a Lisp compiler without lambda.

> it seems like a reach to call this a Lisp compiler without lambda.

I think that's a running gag when implementing "lisp." I can recall seeing some "lisp in javascript" library a while back that also neglected to implement that "minor detail."

Try entering

   (eval. '(lambda (x) x) nil) 

to the REPL with the following definitions:

http://lib.store.yahoo.net/lib/paulgraham/jmc.lisp

Good critique but harsh, could you have at least spared some positive notes at the end of this blazer?

He made something and shared it with us. That's more than 99% of programmers can say.

I have no clue what you are reacting to. His comment was 100% constructive criticism. Everything was a suggestion.

I disagree.

It was an example designed under pretty specific constraints that preclude the suggestions he was making.

Why? Python supports functions pretty well. So adding proper support for functions, like lambdas, can be done quite metacircularly; and thus in a very short code.

If that still takes to many lines for his challenge, leave out linked lists or arithmetic. Lambdas are more important in Lisp, and you can re-create both of them as a library in the language, if you have lambdas.

Fair enough. I really like this sort of post. It's intriguing to see people's interpretations of what a Lisp is, and what a compiler does, and 89 lines is short enough to digest the essence in a blog post.

I guess I should probably come up with my own Lisp implementation now :)