> Why is this quoting the top-level lambda expression arguments? I suspect mostly because the implementation stumbled into the dynamic binding/lexical binding/

> Why is this quoting the top-level lambda expression arguments? I suspect mostly because the implementation stumbled into the dynamic binding/lexical binding/FEXPR traps that hit all the early Lisps. > Here it becomes clear that, in its most bare essential form, beneath the macros and abstractions, LISP actually has an unpleasant nature where name bindings (or assignments) look like a venus fly trap. Ayup. A lot of these problems were addressed by the late John Shutt in his thesis about vau calculus in the Kernel programming language: FEXPRS: https://en.wikipedia.org/wiki/Fexpr https://en.wikipedia.org/wiki/Fexpr John Shutt's vau calculus thesis: http://www.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unrestricted/jshutt.pdf http://www.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unre... John Shutt's Kernel Language--"Revised-1 Report on the Kernel Programming Language" https://core.ac.uk/download/pdf/47187352.pdf https://core.ac.uk/download/pdf/47187352.pdf The "magic" is that the "$vau" operative closes over the environment when it is defined so that it can execute later in that environment--this is the "static/lexical environment". However, when you actually execute the "$vau" operative, you also pass in the "execution/dynamic" environment so that the code that the "$vau" operative runs can choose to do what it wants with the arguments--do nothing, evaluate them in the lexical environment, or evaluate them in the dynamic environment. It's a powerful concept, but difficult to compile so got kind of relegated from the Lisp/Scheme languages. For something which seems to implement it properly, see the "Oh" UNIX shell: https://github.com/michaelmacinnis/oh https://github.com/michaelmacinnis/oh https://www.youtube.com/watch?v=v1m-WEZz46U https://www.youtube.com/watch?v=v1m-WEZz46U I would mumble that the fact that "list" is defined as "cons pairs with a final nil()" is also a pain in the ass. I understand why it was originally done this way, but it makes the idea of a "sequence" abstraction so very much more painful. It's one of the reasons why Clojure dropped it.