コンパイルしたらあなたと合体した
Common Lispでは、
よく似てるけどeqlではない2つのリテラルを含むソースをコンパイルしたら、
コンパイル後には2つのリテラルがeqlになることがあるそうです。
そのことを「2つのリテラルはコンパイラによって合体された」と言うとか何とか。
ちゃんとした定義はこちら
(“similar”は「似ている」ではなく厳密な定義が与えられています)
coalesce v.t. (literal objects that are similar) to consolidate the identity of those objects, such that they become the same object. See Section 3.2.1 (Compiler Terminology).
The term coalesce is defined as follows. Suppose A and B are two literal constants in the source code, and that A’ and B’ are the corresponding objects in the compiled code. If A’ and B’ are eql but A and B are not eql, then it is said that A and B have been coalesced by the compiler.
ということで実際に試してみました。
使用したのはSBCL 1.0.50です。
(defvar a '(a b c)) (defvar b '(a b c))
こちらのソースコードをloadして (eql a b) を試したところ、NILになりました。
しかし、compile-fileしたものをloadすると、 (eql a b) の値はTになりました。
まさに2つのリテラルが合体したという感じです。
ちなみに、CLISP、Clozure CL、Allegro CLではcompile-fileしてもNILのままでした。
smilarなリテラルがたくさん出てくるようなソースコードでは、
リテラルを合体した方が、コンパイル後のバイナリファイルのサイズや、
ロードした際のヒープの使用量を節約できそうですが、
コピペを繰り返したソースでもない限り、効果は薄いような気がします。
誰かcoalesceの効果の程を測った人とかいないんでしょうかね。
[…] さて、compile-fileした場合Tになる理由は前回のエントリを読んでください。 ＃前回の実験ではACLではcoalesceは行われませんでしたが、 ＃今回の実験ではcoalesceが行われているようです。 […]
くそー日本語に訳せよ。
酔っ払ってたら、よまれへんがな。
> (“similar”は「似ている」ではなく厳密な定義が与えられています)
似てても eql でNILとは、似てないやん。