Steel Bank Common Lisp 2.0 | Hacker News Reader

Steel Bank Common Lisp 2.0

sbcl.org

209 pointsbjoli35 comments

Open articleView on HN

SBCL was forked from CMU Common Lisp 20 years ago, which was started as a project as Spice Lisp at CMU 39 years ago.

did we reach root ?

http://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part2/fa... Apparently, Spice is a derivative of MacLisp.

A "dialect" of MacLisp, the page says. I doubt there was any code in common.

The LOOP macro may have been derived from MacLisp.

If we ask what was Spice Lisp based on, I don't know if it used sources from a prior Lisp. Though there was an earlier C-MU Lisp, which was based on UCI Lisp, Stanford LISP 1.6,... Generally Spice Lisp was in the Maclisp camp.

SBCL folks recently had a workshop in Vienna, Austria: http://www.sbcl.org/sbcl20/

Yeah, was quite surprising to find out on the Intranet. As far as I know, the company that hosted the workshop doesn't use any Lisp dialect at all^^

https://news.ycombinator.com/item?id=21842644

Worth noting is that according to the Download page[1], only amd64 linux has had 2.0 binaries released. None of the other platforms has it yet (so macOS and Windows doesn't [yet])

- [1] http://www.sbcl.org/platform-table.html

Windows amd64 as well now.

It’s incredibly easy to build yourself. Literally just

    sh make.sh --fancy

(--fancy isn’t even required, but builds all optional additions.)

Installation?

    sh install.sh

I haven't found it that easy.

My package manager installs version 1.4. I downloaded the version 2.0 package from the website, and ran the "install.sh" script per the Getting Started instructions for installing a binary. When I tried running it I got the following error:

/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /usr/local/bin/sbcl)

I couldn't find a "make.sh" file in the package that I downloaded, and I'm not enough of an expert to solve the GLIBC version error problem.

make.sh is included in the source release [0]. Download that, not the binary release. The binary release is only needed for either bootstrapping or for a compatible binary installation. (Evidently your glibc isn’t compatible with the binary release; building from source should be as easy as I suggest above.)

Once you install it, you can uninstall your system-provided SBCL.

[0] It’s linked at the top of http://www.sbcl.org/platform-table.html

Thank you. That worked perfectly for me.

Is there any reason this merited a major version bump or it happened because it remained as v1 for too long?

From Christophe Rhodes[1]

> So, I'm not particularly thinking of sbcl-2.0.0 in terms of semantic

> versioning. In fact, my loose plan for further releases is to aim for

> about 11 releases a year, and increment the second-level number every

> year or so, to keep a rough alignment with calendar years. Our users

> should be trained by now that every release is a potentially-breaking

> release, right?

- [1] https://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/877...

Every decade major version number increases.

How is multi processor and native multi threading support and support of the two concepts in the GC?

The GC is neither parallel nor concurrent. Luis Oliveira implemented a parallel GC in SBCL but it was slower IIRC.

The garbage collector is a stop-the-world collector, but other than that, this implementation has great multiple core / multithread support.

Congratulations!

Apparently released today :)

I appreciate the commitment to semver, it seems that the breaking change is a rather small one, unless I'm missing something.

The not-really-breaking change is not actually related to the version number. There is approximately 0% chance that somebody depends on the presence of that symbol in features. And there have been more actually noticeable compatibility changes with minor version bumps.

True, and a reason to applaud the changelog: it lists a potential breakage just because the is, well, a potential for breakage.

Yes, in reality, I'd be amazed to find code that actually breaks.

> I appreciate the commitment to semver

There is no commitment to semver from SBCL's side. Rather, it's trying to follow calendar years with at least one release each of the 11 months and a major release in the end of the year.

Uh, I take it back then. I get this versioning scheme for something that don't have a reasonably application for semver like an operating system for instance, but a programming language? I don't really see the point. If you go that way you might as well tag it "SBCL 2020" or something like that to make it clear.

But I suppose that's pure bikeshedding and it doesn't really matter.

I'm sure SBCL is committed to follow the Common Lisp standard, so as long as you don't stray outside of that you don't have to worry too much.

Is that feasible? Last I used Common Lisp, I seem to recall the spec being rather ambiguous on a number of important practical points, so any real program couldn't depend on only CLTL2.

For example, Maxima lists a number of implementations that can compile it, and says "Ports to other ANSI Common Lisps should be straightforward and are welcome" [1]. The source code is full of #+ #- conditionals.

[1]: http://maxima.sourceforge.net/lisp.html

CLtL2 is not the spec for ANSI CL. The spec was published a bit later and is a different document.

The actual spec for ANSI CL is basically almost the same as this document : https://franz.com/support/documentation/cl-ansi-standard-dra...

ANSI CL is a spec of the language. Programs like Maxima use a lot of features not covered by the language specification and Maxima has been written over a long time and has to deal with changing languages, operating systems and implementations, too.

For example the Common Lisp standard does not say anything about how an executable can be created. Maxima surely want s to do that. There are mow also libraries, which provide common interfaces for a bunch of general cases, though.

I write a lot of CL, and it’s reasonably easy to write standard-conforming code that just works across multiple implementations and, if you need something not standardized like sockets, TLS, or threads, there are fairly high-quality and “standard” portability libraries that make it easy to avoid reader conditionals most of the time.

SBCL is an implementation. The programming language Common Lisp is set in stone by a standard.

Does that matter? SBCL includes a lot of nonstandard extensions.

It matters a lot. But the extensions are important and warrant compatibility tracking.

Reply on news.ycombinator.com