@vnikolov @screwlisp @hairylarry @jns @dougmerritt @ksaj @ramin_hal9001 @tealeg

I haven't looked at all at the specifics, so in this message I'm speaking purely in abstract terms in case it helps, but this looks like a situation where even absent a standard, a common library that papers over the differences for certain common kinds of operations that are needed to support a variety of libraries would be the right target. Such thing could grow up to be a standard.

An important thing to understand about ANSI CL is that it was not designed from scratch in a vacuum, but grew from CLTL (84), which was already a de facto standard.

And likewise CLTL was not designed from scratch but grew out of the Maclisp family, consolidating well-used/liked features.

By all of this I mean that establishing current practice ahead of new design is a way of ensuring relevance and commitment ... and of field testing gotchas.

Here we're not talking about the base language, so this is not a fight between scheme and common lisp. An appropriately designed library might even bridge both of those underlying languages. Rather, this is about what domain specific vocabulary is necessary and feasible in order to write a variety of packages.

Because, and I might be misunderstanding, so correct me if I'm wrong, I take Vassil's point to be that the real investment is in the libraries and those are what need to remain stable. They need some bridge technology that insulates them from the variabilities of the underlying languages and systems, not just operating systems but editing systems.

I would add to his portability concern that I think of new major releases that break things as portability issues as well, just across time instead of space. If emacs 30 can't run a library that emacs 29 did, and I classify that as a portability problem. And a much more serious one than is commonly acknowledged. It is just plain unreasonable and unacceptable that the core language continues to change so much from release to release that it undoes the hard work.

At Symbolics, back in the 1980s, there were some notable situations where we made incompatible changes that broke things. Someone internally commissioned a report on what it cost each of our customers to accept an upgrade. It was eye-opening. It was in the TENS OF THOUSANDS OF DOLLARS PER CUSTOMER. In 1980s dollars. That would be way more today. Just to receive a software upgrade. Imagine that cost aggregated over an entire customer base. That was not just cost to them but it was OPPORTUNITY COST where lisp could have been used to make inroads into the marketplace. Instead, resource was squandered treading water, maintaining The identical functionality as one had before, but poorer. It meant no one was putting that money into killer apps, just into not breaking the previous year's victories. It hurt all of us.

And even in free software, one of the things I really hate about free software by the way, even though there are other advantages, there are still costs to maintaining it. They just don't show up on a balance sheet. But real people's lives are consumed, and can easily be wasted. The fact that things are free means that no accounting is done, but does not mean that nothing was lost.