6 ms·

Fun fact I learned from a Func Prog podcast: the name Steel Bank is a play on it's origin as Carnegie-Mellon Common Lisp (Carnegie made his fortune in Steel, wh

by taolson 2mo ago

Fun fact I learned from a Func Prog podcast: the name Steel Bank is a play on it's origin as Carnegie-Mellon Common Lisp (Carnegie made his fortune in Steel, while Mellon did so with Banks): https://www.sbcl.org/history.html https://www.sbcl.org/history.html

p_l 2mo ago
There's another wordplay in the name. Namely, that "SB" stands for "Sanely Bootstrappable" - something that the CMU Common Lisp was unable to do
- jojohohanon 2mo ago
  In my first job, grumpy Martin had as one of his many indispensable tasks, to build cmucl. (Itasoftware, one of the main lisp shops of the age)
- guenthert 2mo ago
  It is my understanding that easing bootstrap was the original motivation of the fork of CMU CL. I'm a bit confused about that, since CMU CL supports compilation to byte-code (which should make a port to a new architecture comparatively easy), a feature which was dropped in SBCL.
  - p_l 2mo ago
    The sane bootstrap is not about porting to new architecture, but about building the compiler from source in the first place. CMU CL effectively requires that you use the same version of CMU CL to build it, IIRC, which in practice meant you had to first load the changes into older CMU CL image - overwriting core components, and then use that image to compile new version. The difference with SBCL is that it can compile so long as you have any CL implementation that handles certain broad, but not complete, subset of ANSI CL. It does it by being able to compile itself in sort-of sandboxed state hosted within another CL image, and then using that compiler to build itself, without requiring to modify the host compiler like CMU As for the bytecode, as far as I recall CMU CL did not have bytecode compiler at all - it had evaluator option, which was indeed dropped for a long time from SBCL but was recently reintroduced, partially to support efforts such as porting Kandria [1] to Nintendo Switch [1] https://kandria.com/ https://kandria.com/
    - jhgb 2mo ago
      > As for the bytecode, as far as I recall CMU CL did not have bytecode compiler at all The byte code compilation option is described in CMUCL documentation, section 5.9 Byte Coded Compilation: https://cmucl.org/docs/cmu-user/html/Byte-Coded-Compilation.html https://cmucl.org/docs/cmu-user/html/Byte-Coded-Compilation....
      - p_l 2mo ago
        Ah, with how cmucl was problematic to get running I never delved that deep. It indeed is not present in SBCL. That said, as mentioned, it gave no real impact on bootstrappability nor portability
- pfdietz 2mo ago
  That's more of a backronym.

by taolson 2mo ago

p_l 2mo ago

There's another wordplay in the name. Namely, that "SB" stands for "Sanely Bootstrappable" - something that the CMU Common Lisp was unable to do

jojohohanon 2mo ago
In my first job, grumpy Martin had as one of his many indispensable tasks, to build cmucl. (Itasoftware, one of the main lisp shops of the age)
guenthert 2mo ago
It is my understanding that easing bootstrap was the original motivation of the fork of CMU CL. I'm a bit confused about that, since CMU CL supports compilation to byte-code (which should make a port to a new architecture comparatively easy), a feature which was dropped in SBCL.
- p_l 2mo ago
  The sane bootstrap is not about porting to new architecture, but about building the compiler from source in the first place. CMU CL effectively requires that you use the same version of CMU CL to build it, IIRC, which in practice meant you had to first load the changes into older CMU CL image - overwriting core components, and then use that image to compile new version. The difference with SBCL is that it can compile so long as you have any CL implementation that handles certain broad, but not complete, subset of ANSI CL. It does it by being able to compile itself in sort-of sandboxed state hosted within another CL image, and then using that compiler to build itself, without requiring to modify the host compiler like CMU As for the bytecode, as far as I recall CMU CL did not have bytecode compiler at all - it had evaluator option, which was indeed dropped for a long time from SBCL but was recently reintroduced, partially to support efforts such as porting Kandria [1] to Nintendo Switch [1] https://kandria.com/ https://kandria.com/
  - jhgb 2mo ago
    > As for the bytecode, as far as I recall CMU CL did not have bytecode compiler at all The byte code compilation option is described in CMUCL documentation, section 5.9 Byte Coded Compilation: https://cmucl.org/docs/cmu-user/html/Byte-Coded-Compilation.html https://cmucl.org/docs/cmu-user/html/Byte-Coded-Compilation....
    - p_l 2mo ago
      Ah, with how cmucl was problematic to get running I never delved that deep. It indeed is not present in SBCL. That said, as mentioned, it gave no real impact on bootstrappability nor portability
pfdietz 2mo ago
That's more of a backronym.