| > To that end, how things are actually implemented takes a trip to assembly. Don't confuse “defined” with “implemented”. This is the entire point to having an axiomatic semantics! > My point was that you don't typically see c constructs explained in terms of other c constructs. Languages can't be entirely defined in terms of themselves. At some point you need to drop down to something else. If most of Lisp is defined in terms of other Lisp constructs, that is perfectly fine, but, for my purposes, i.e., proving things about programs, there are two mutually exclusive possibilities: (0) The semantics of Lisp is the semantics of its primitive forms, and derived forms are just Lisp's standard library. (1) So-called “derived” forms have an abstract semantics of their own right, and their implementation in terms of so-called “primitive” forms is, well, an implementation detail. So, my answer to “most of Lisp is defined in terms of Lisp itself” is “that's cute, but how mathematically elegant is the part of Lisp that is not defined in terms of itself?” |
So, by all means, keep arguing points I'm not making. I was offering what I suspect the parent post meant by it being easier to reason using the mechanics of the language. Nothing more.