Lisp規格ではコンパイル時に弾くことってできないんでしょうか。......と思ってHyperSpecにあたってみましたが、コンパイル時にアリティの不整合を検知した場合には、エラーにしてしまうコンパイラがあっても良さそうではありました。Constraintsを眺める限りでは、どちらかといえば、コンパイラ動作の方に重きを置いているように見え、再定義されなくても良い場合を幾つか挙げています。逆に再定義が保証されることを主として考えるとすると、少なくともnotinline宣言がついてない場合の再定義は、関数が実行時に確実に置き換わることは期待できなさそうです。コンパイラ/インタプリタ動作の整合性とは別に、アリティのチェックについても記載がありますが、エラーは、実行時もしくはコンパイル時に挙げるとあります。Calls上記は、関数呼び出し時のエラーについての規定なので、基本的に実行時エラーだけで良さそうにも思えますが、マクロ展開等も考慮するとコンパイル時も含めないといけないのでしょうか。callの観点からもコンパイル時に検出することも可能ではありそうです。callの観点からすると、アリティの不整合はコンパイル時にエラーにできそうです。Calls処理系の実際を確認する呼出しのアリティに不整合があった場合にコンパイルエラーになっても良さそうではあるのですが、実際の処理系の挙動を確認してみました。x))下記のように実行してみます。1処理系のメジャーなところは一通り確認してみましたが、コンパイルエラーにする処理系はECLのみのようで、他は警告は出すもののコンパイルは通し、faslをloadして実行したら当然実行時エラーです。Lispってこんな感じの動作でしたね、というところ。ECLの動作のほうが意外かもしれません。警告ありアリティの不整合をコンパイルエラーにしたいさて、規格上はコンパイル時にアリティの不整合を検出してエラーにしても良さそうだけれど、実際のところデフォルトでそういう挙動をする処理系は、殆ど存在していないことが分かりました。Lispなので、工夫はあれこれできそうですが、とりあえずコンパイラマクロを試してみましょう。何もしないコンパイラマクロを定義するのみですが、展開時に引数チェックでエラーになることが期待できます。警告あり軒並エラーになると予想していましたが、コンパイルが通ってしまうものもある様子。これは、積極的にエラーにする他ないのかもしれません。いうことで下記のように書いてみました。CLはコンパイルを通す様子。CL、CMUCLはそういうポリシーなのでしょう。Lispでアリティの不整合をコンパイルエラーにする方法を探ってみましたが、アリティの不整合のコンディションを作成*break-on-signals*に適宜設定コンパイラマクロで引数チェックの組み合わせで大抵の処理系では実現できそうです。ちなみに、型の不整合もチェックしたいところですが、SBCLであれば、今回のコンパイラマクロの手法を応用して、deftransformあたりを使えばできなくもなさそう。