追記: 毎月末にSBCLのリリースがあるよ: https://www.sbcl.org/all-news.html

よくわからない :-(

それはすごく面白いし、私が思ってた「20世紀中頃の廃業した地域銀行から来た」という半分の推測よりもずっと納得できるね。

うわ、ずっとSは（ガイ）スティールに関するものだと思ってた。

このコメント好きだな: 「ちなみに、これを3週間前にリリースしたんだけど、HNでこれについて聞いたのはあなたが初めてだと思う。メールでの質問は一件あったけどね。これはスプラッシュなしのダイブってことでいいんじゃない？」知らなかったよ、HN中毒なのに！

このsbcl用のArcのバージョンは、HNで使われてるのとは違うのかな？: https://github.com/pauek/arc-sbcl それと、sbclで動くAnarkiのバージョンはないの？: https://arclanguage.github.io/

みんなSBCLとEmacsに集中しすぎて、Lispのツールについて文句を言ってる。 そうだね、LispWorksやAllegroは高い商業プロジェクトだからね。SBCLはデファクトスタンダードのオープンソースの選択肢なのに、もっと良いツールがあればいいのに。Emacsは本当に信じてる人には素晴らしいけど、私は普通のVSCodeユーザーだから。スタートアップでは理由があってそれを正当化できないけど、個人プロジェクトでCommon Lispをもっと使いたいな。でも時間が限られてるから、ClojureやRustの方が好きなんだよね。

普段からemacs使ってるよ（実際、今も動かしてるし）。その不満は全く正当だと思う。emacsは色々な面で素晴らしいけど、他の面では本当にひどい。まあemacsは置いといて、SBCLのツールは合理的だと思う。最近lispをあまり使わない理由は、ツールのせいじゃなくて、Common Lispのライブラリエコシステムが部分的な実装や放棄されたコードベースの荒れ地だから。LLMは特に「初心者向け」の言語、例えばGoみたいなメインストリームの言語を書くのが得意だと思う。だから、AllegroやLispworksをSBCLより選ぶ理由がわからないな。手動でlispを書くのが好きで、SBCLにはない特定の機能が必要な人以外は。そういう機能はほとんどないと思うけどね。

LispWorksとAllegroはどちらも面白いけど、IDEの提供がすごく限られてると思う。コロナの時にCLをいじってた時以来、どちらも使ってないけど、記憶によれば、コードを書く基本的なIDE体験がひどかったんだよね。オートコンプリートが貧弱、構文ハイライトがイマイチ、インターフェースが使いづらい。ほとんどの議論では、彼らのコンパイラのためにだけ推奨されていて、IDEの提供についてはあまり言及されてない。

Nichimenの作品を見て以来、ずっと謎だった。価格は当時考えるのも無理なほどだった。

両方使ったけど、商業的にAllegroCLを生産環境で使ってたんだけど、どちらも期待外れだった。特にAllegroCLは値段と約束に対してね。

Aboutページから: >SBCLは、カーネギーメロン大学で作られたCMU CLからほとんどのコードを引き継いでいる。システムの一部（特にブートストラップ）には大きな変更が加えられているが、基本的な部分（Lispの抽象を基盤となるハードウェアにマッピングすること、コンパイラの基本アーキテクチャ、ランタイムサポートコードの多く）はわずかに変更されただけだ。インターフェースやアーキテクチャには十分な変更が加えられているので、新しいシステムをCMU Common Lispと呼ぶと混乱を招く。世界にはCMU CLという名前の互換性のないシステムが複数必要ないからね。でも、システムを動かすために大変な労力をかけたCMUのハッカーたち（およびポストCMUのCMU CLハッカーたち）からの系譜を認めるのは適切だ。だから、このシステムはアンドリュー・カーネギーとアンドリュー・メロンがそれぞれ大金を稼いだ産業にちなんでSteel Bankと名付けられた。

CMUへの公式な言及に加えて、名前の由来はもう一つある。SBCL - Sanely Bootstrappable Common Lisp。SBCLがCMUからフォークされたとき、CMU CLとは違って、どんな reasonably completeなCommon Lisp実装でもコンパイルできるように大きな努力がなされたんだ。CMU CLは基本的に自分自身でしかコンパイルできず、同じバージョンであることが好ましかったから、コンパイルや特にクロスコンパイルはCMUCLプロセスの内部状態を「新しいバージョン」に持っていく複雑なプロセスだった。SBCLは、コアのSBCLコンパイラ部分をほぼ完全なANSI CL実装でホストできるようにロジックを大幅に見直した。そしてそれを使って完全な形をコンパイルする。つまり、SBCLのソースtarballを手に入れて、GNU clispやECL、Clozure CL、さらにはGNU Common Lispのどれか、商用実装のいずれかを使って、もちろんCMUCLも含めて、Cコンパイラ（薄いランタイムサポート用）を使って、数コマンドで完全で問題のないSBCLリリースをビルドできるってこと。

スキームがなかったら、CLを喜んで使うよ。

Coalton [1] はコモンリスプにHaskellスタイルの型（型付きリスト、型クラス、パラメトリックポリモーフィズムなど）を追加して、SBCLで特に効率的なコードにコンパイルするよ。 [1] https://coalton-lang.github.io/

あなたの非同期のやつは、SBCLのスレッドインターフェースやlparallel、bordeaux-threadsとどう違うの？

例えば、リストの要素タイプを特化できない。確かに、それはCLの違反になるか、DEFTYPE以外のもので提供する拡張になるね。DEFTYPEの本体は無限再帰できないから。cf https://www.lispworks.com/documentation/HyperSpec/Body/m_def... >もしすべての関数に(declaim)しようとしたら、Pythonと比べても型がどれだけ曖昧で不十分かすぐにわかるよ。確かにそうだけど、1) コンパイラ自体が使ってるし、cpythonは現在アノテーションを無視してるし、2) ランタイムとビルドタイムの型付けは同じ意味論と構文を使ってるから、https://github.com/agronholm/typeguardみたいなバンドエイドは必要ないよ。でも、CLの型システムは多くの点で不足してるね。実用的な利点と追加の難しさの順で（多分）：再帰的DEFTYPE、型付きHASH-TABLE（キーと値のこと）、CLOSスロットの静的型付け（侵襲的、https://github.com/marcoheisig/fast-generic-functionsみたいな）、...、ARRAYを超えたパラメトリック型付け。

Emacsは必要ないよ。いや、必要だよ。

「Mr. Potatoheadが逃げ出した！」が私のお気に入りだよ、たしかFedora Linuxのディストリビューションからだったと思う。