Lisp inspires some people to work at the implementation level.<p>My TXR Lisp (<a href="http:&#x2F;&#x2F;www.nongnu.org&#x2F;txr" rel="nofollow">http:&#x2F;&#x2F;www.nongnu.org&#x2F;txr</a>) has strong ties to Common Lisp, but it does certain things which I&#x27;ve been able to do easily due to working at the implementation level.<p>For instance, I have regular cons cells as well as lazy cons cells, both of which satisfy the consp function, and are recognized by all the library functions, from car and cdr onward. If this were develpeed in an existing Lisp, it would require rewriting the library from scratch. E.g. not using the standard car, cdr, mapcar and so on.<p>Another example is that forms can optionally express Lisp-1 style evaluation for those arguments which are symbols. This is sugared over with square brackets.<p><pre><code>  ;; list is in the function namespace, but resolved
  [mapcar list whatever]
</code></pre>
Implementing this correctly means writing your own code walker; it&#x27;s not just &quot;add a macro and hand off the code to Lisp&#x27;s evaluator&#x2F;compiler&quot;.  The exact rule is that the closest lexical binding of the identifier is used, whether it is a function or variable; and if there is no lexical binding, then the global one is used. If both a function and variable of the same name exist globally, then preference is given to the variable binding. It doesn&#x27;t end there: symbol macros have to be handled properly: in [a b], a or b or both could be symbol macros. But they get shadowed by function bindings which are lexically inner:<p><pre><code>  (defsymacro ((m whatever))
    (flet ((m () ...))
       (m ...) ;; unambiguously function
       (list m) ;; expanded as symbol macro
       [m ... m ...])) ;; function everywhere 
</code></pre>
Lisp has always been a family of languages. From almost the very beginning, there were numerous dialects. Every major institution that had Lisp activity had its own dialect!<p>It is in recognition of this that the late John MacCarthy expressed his wish that no dialect be just called &quot;Lisp&quot;.<p>Forty years ago you could have said, &quot;if Lisp is go great, why do we have MacLisp, InterLisp, BBN Lisp, ...&quot;<p>Part of the reason Lisp is great is that it teaches programmers to fish.