| > no TCO Neither does Emacs Lisp nor ABCL. Yet they are Lisps by your definition. > different approach about side effects (-> avoid) Though not precluded. You can write Clojure with side-effects, but to do so you need to be explicit about it. > different idea of OOP (-> avoid) Which says nothing about the language or its Lisp-nature. Clojure has generic dispatch with multimethods, supporting runtime polymorphism. As you say later, "OOP" is meaningless since it's definition is vague, so using this as a reason for Clojure to not be a Lisp is odd. > Just think of it: zero lines of code is shared. Are saying that a lisp is only a 'Lisp' if you can freely share code between them? Without modification? If the names used for functions aren't the same, then that disqualifies it from being a Lisp? Your position seems to be that unless the lisp is a direct descendant of Lisp 1.5 then it cannot be called a Lisp. In addition to Clojure, this disqualifies Scheme (and its dialects.) Different Lisps (by your definition) take different approaches to things like namespace separation (Lisp-1 vs. Lisp-2) and scope (dynamic vs. lexical). These differences can be subtle and lead to hard to find bugs when sharing code. > My problem with that broader idea of 'Lisp': it is fully vague and it has no practical implications. Yet you have put a stake in the ground and defined the broad idea of 'Lisp' as an entity that shares its roots with the ideas in MacLisp. |