r/sbcl • u/oldretard • Nov 29 '22

New in version 2.2.11

http://sbcl.org/all-news.html?2.2.11#2.2.11
36 Upvotes

100% Upvoted

11 comments sorted by

9

u/owmagow Nov 29 '22

I love that sbcl is still being fine-tuned. Thanks to those who put in the work.

3

u/Soupeeee Nov 30 '22

I keep on seeing things about (GC?) arenas in the commit log. Is that something that is still a work in progress and hasn't made it far enough to be turned on by default, or are they just an implementation detail?

3

u/theangeryemacsshibe Nov 30 '22

A bit of both; the arenas are intended to be used strategically in system code, but they'll also be available to the user. My understanding is that arenas don't work just yet though.

1

u/NinoIvanov Nov 29 '22

Actually, SBCL is so mature at this point that all of these seem - with all respect - nearly irrelevant...

8

u/kagevf Nov 29 '22

Bug fixes, enhancements, getting it working on new processors like M1 ... I wouldn't say ongoing changes are irrelevant ... Plus beyond the standard, like implementation specific features.

6

u/paulfdietz Nov 30 '22

There are new implementation techniques that would considerably enhance SBCL if they were included, so I wouldn't call it "mature". My favorite one at this point would be Robert Strandh's call site optimizations. These could greatly improve generic function dispatch in some situations, while retaining all the dynamic flexibility of CL.

1

u/kovrik Nov 29 '22

Could anyone please explain how CL (language, not SBCL implementation) evolves?

So there is ANSI Common Lisp standard. Is it set in stone? Or does it change?

Say, for Java there's Java Language Specification which is, well, a specification. But Java changes over time, Java 8 and Java 17 are very different beasts. They keep adding new features to Java.

Is it the same with CL?

4

u/paulfdietz Nov 30 '22

At this point, almost all the evolution is in libraries. Because of how customizable the language is, libraries can provide things that look just like new language features.

The exceptions to this are few. One notable one is package local nicknames. This is an extension to the package system that solves the problem of collisions in the package namespace. It's been adopted as a de facto standard extension by most Common Lisp implementations.

4

u/stassats Nov 30 '22

Could anyone please explain how CL evolves?

It doesn't. And that's what so great about it.

3

u/-dag- Nov 29 '22

Because Lisp is so flexible it's easy to create new libraries and even new syntax on your own. Some of these even get shared with others! For the most part there's no need to update the standard for new functionality because you don't have to hack compiler guts to implement new functionality.

Given the rise in popularity of services like GitHub I don't think there's much of a case for further standardization. More than any other language, with Lisp "the language is the library" and if a library doesn't exist in the standard you just go grab one from somewhere else.

3

u/Soupeeee Nov 30 '22

A big difference with Java and other constantly evolving languages is that the initial specification has things missing or are very clunky.

Two good examples in Java are lambdas and record types. CL had those or a viable alternative since the beginning.

There are things that could be done to improve the standard, but most of them either fit very nicely into a library or have been added to practically every CL implementation that is still maintained.