@screwtape @pkw @mnl

As I think I mentioned recently (in my LispNYC talk?), McCarthy, at least by time of the standards, wanted there not to be any single dialect of Lisp that claimed the unadorned name Lisp. So there was syntactic room for dialects to compete.

There was discussion in design of EuLisp, an influence on ISLISP, about layers. EuLisp had 3 layers, I think. That layering didn't make it into ISLISP. I don't recall it being proposed for CL, though I might be forgetting at this point.

It was never clear to me, though I was not part of their community, whether the underlying language was a subset of, or just an implementation language for, the surface language.

My only very concrete memory was that someone wanted some transform T such that L1 = T(L0) to be applied at some point. Maybe this came up in the CL macros committee. I was pretty adamant that CL did not need macro "hygiene" like Scheme has.

The urgency of that is due to Scheme's choice of being what I called a Lisp1 (the names Lisp1 and Lisp2 in this context are no relation to versioning you referred to in reference to Lisp 1.5, but are abstract categories that address how many variable namespaces are in the language).

Various characteristics of CL, including but not limited to being a Lisp2, helped insulate it from name collisions in the macro system, so the macro system didn't need to have formal hygiene like in scheme, or so I claimed.

I don't think the CL community wanted to change its macro system. Indeed I'd go so far as to say the easy writing of macros is strongly correlated with the rapid success of the family of Lisps that became CL. Breaking something that was succeeding wildly seemed ill-advised, or at least that's how I perceived things. Obviously this was a community discussion.

The fact of a package system rather than a lexical module system was also relevant to this. It's a subtle issue, but important. Scheme is a language defined by its programs' texts. In Common Lisp, the language semantics is on objects.

Speaking only very approximately here for brevity, the compiler operates on lists made of conses and symbols, not text made of parens and alphanumeric tokens. So there need be no source text in CL. Gensyms can easily be created by macros for variable names in CL, something you can't do in Scheme without help of a hygienic macro system to do rewrites for you. The use of gensyms further insulates macros from name collisions that would be routine in scheme if it had a CL-style macro system.

I think the way in which the package system, the macro system, and the namespacing form a kind of ecosystem is ill-understood by most users, even though they're comfortable with the effect. It only matters to understand it if someone suggests changing one of these without changing the others.

It's sometimes hard for someone from the Scheme community to understand why macro hygiene isn't needed in CL if they don't get how packages are fundamentally different than lexical namespacing. So they propose isolated changes thinking it will solve a problem that isn't really there. It's also hard for them to get why CL users see such proposals as adding complexity rather than removing it.

Goung one level meta, it's worth observing that there are not good language features and bad language features, but good within a context or bad within a context. People sometimes get a feature they like and want to impose it on other languages, not seeing that's harmonious in some and not others.

Context matters in assessing abstracts like goodness. It's the harmony of the ecosystem that matters. Adopting change, even well-meaning change, can be very disruptive, sometimes causing unexpected cascade effects (and community cost in both dollars and happiness) one doesn't realize will be needed.

Some of this is covered in the paper Gabriel and I wrote called Technical Issues of Separation in Function Cells and Value Cells. We were tasked by X3J13 to write such a thing because we disagreed on how things should go and between the two of us would likely hit all the issues. :) If you read carefully, you'll see the paper is a kind of debate between us where one would say something and the other would say "yeah, but.." and inject counterpoint. (This is the origin of the namespacing categories Lisp1/Lisp2. Also, the original paper, titled just Issues of Separation in Function Cells and Value Cells was longer and more X3J13-specific. We tightened it up for journal publication, mostly at Gabriel's insistence, as "Technical Issues..." to emphasize some dropped politics.) https://www.nhplace.com/kent/Papers/Technical-Issues.html

I may be far afield and I have no idea if that answers your question or just creates more questions, so I'll stop. :)