Windows Terminal に於ける SBCL-REPL の挙動について。

日記：２０２４年４月９日

#Lisp のお話です。

読者の皆さん、今お使いのブラウザで、次の漢字が正常に表示されているでしょうか？

『𩸽』

「魚」に「花」を合わせて、「ほっけ」と読みます。
居酒屋の焼き魚の定番ですね。

この『𩸽』は比較的最近 Unicode に登録された文字で、諸般の事情から、他の一般的な Unicode 文字に比べて、２倍のメモリーを消費します。
これをサロゲート・ペアと言います。

Windows Terminal で SBCL の REPL を起動したとき、このサロゲート・ペアが悪さをしていたので、皆さんと共有したい。

まず、Windows Terminal を開いて、SBCL の REPL を起動し、以下の文を入力・実行してください。

(print (length "𩸽"))

結果は「2」です。
１文字なのに、SBCL の REPL は「2」という間違った答えを返します。

次に、この文を「test.lisp」というファイルに保存し、コマンドラインから、

sbcl --script test.lisp

と実行してみてください。
結果は「1」になるはずです。

つまり、同じ関数呼び出しなのに、REPL での実行と、ファイルを読み込んでの実行で、結果に差が出てしまうのです。
正直、気持ち悪いです。

再び SBCL の REPL を起動して、以下の文を入力・実行してください。

(load "test.lisp")

結果は「1」です。

同じ REPL なのに、そして同じ文なのに、直接入力とファイルからの呼び出しで挙動が違うのです。

おそらく、入出力を請け負っている Windows Terminal と SBCL との連携が上手く行っていないのだろうと思いますが、マジで気持ち悪いです。やめて下さい。

Unicode サロゲート・ペア周りは、ほんと鬼門ですね。
javascript でも、サロゲート・ペアに起因するインデックスや文字数のズレが生じています。

３０年前、「世界中の文字を全部あわせても、２バイトあれば行けるやろ」と高タカをくくっていた英語圏の Unicode 策定者さんたちには、猛反省して欲しいですね。
日本人としては、「だから３０年前に『２バイトじゃ足りない』って、あれほど言ったのに……」って感じです。

今さら昔のことを蒸し返しても仕方ありませんが、とにかく javascript などのプログラミング言語は世界の基盤技術ですから、早く不具合を何とかしてほしいです。

#SBCL
#プログラミング
#コンピュータ
#日記