> Are you saying Coalton as an embedded language should be introduced out of the box?
Not the whole language as is but proper algebraic types at least. Just like most modern languages do.
> Why not? Common Lisp as a living and extensible language now evolves by adopting de-facto standard (trivia for pattern matching, bt for native threads, usocket for network, ASDF for build system, etc). Why need a committee or other form of authority to prescribe what everyone gets to use when we have a maximally democratic process?
Totally a valid point but then something like Compact Lisp proposal to strip the language to the bare minimum and extract everything out in libraries would make way more sense than the huge and only half-used CL standard we have now.
If you want Scheme, go use Scheme because these are not arguments for Common Lisp. There is tons of value in the CL specification being this big and I'm happy I can still run code I wrote more than 25 years ago (or third party code written more than 50 years ago) without any issues.
Generally, contemporary folks that propose improvements to the CL spec tend to be misinformed / misguided and/or lacking experience to realize why their proposed improvements are bad ideas.
How would algebraic types work with SLIME? If I remove a constructor from my algebraic type, what happens to values of that type that are built with that constructor that're stored in globals?
In the same way that non-hygienic macros in a Lisp-2 with a CL-style package system are a local optimum, many non-obvious design choices in the Common Lisp type system and CLOS make SLIME "just work" in almost every case.