モジュールをバイトコンパイルしています。それは私にこの警告を与えます:
Warning: cl package required at runtime
なぜこれが警告なのですか?私はcl
パッケージを使用していることをよく知っています。実際、モジュールには(require 'cl)
ステートメントがあります。
cl
のものの使用に何か問題がありますか?
もしそうなら、公開された回避策のリストはありますか?私が使用する主なものはmapcan
とdelete-duplicates
です。
この警告の理由は、Elispでパッケージclを使用したくないGNUポリシーですが、完全に禁止するのも愚かです。そこで、警告を表示することにしました。 。
あなたはより多くの情報を見つけることができます ここ
誰かがcl
の適切な使用を求めてこれを読んだ場合に備えて、ここで説明するメソッドは非推奨になりました。
少なくともemacs24の時点では、cl
の代わりにcl-lib
を使用するか、マクロで十分な場合はcl-macs
を使用する必要があります。これらは、クリーンな名前空間で機能するcl
の新しいバージョンです。例えば。 defun*
の代わりにcl-defun
があります。
古いcl
-パッケージは、下位互換性のためだけのものであり、新しいコードでは使用しないでください。
ElispとCommonLISPの間には名前空間の衝突がありますが、clパッケージは、繰り返される名前にアスタリスクを追加することでそれらを回避します。たとえば、Common LISPバージョンのdefunを実装しますが、それをdefun *と呼びます。結果として、clとElispの間に名前空間の衝突はなく、(require'cl)の場合は非常に安全です。
ばかげた警告を取り除きたい場合は、変数をカスタマイズしてくださいbyte-compiler-warnings。[1]これにより、コードをコンパイルするときに警告がオフになります。コードを配布すると、他の誰かがコードをコンパイルしたときに警告が返される可能性があります。これを発生させたくない場合は、次のコードを使用してください。
(with-no-warnings
(require 'cl))
同様の方法で、LISPフォームに関するバイトコンパイラの警告を停止できます。[2]一般的にはお勧めできませんが、この場合は正当化できる可能性があります。
コード:
(eval-when-compile
(require 'cl))
警告は削除されますが、これを行う場合にのみ、パッケージのマクロを使用できます。マクロはコンパイル時に評価され、Elispは実行時にマクロについて知る必要はありません。 clだけでなく、任意のパッケージのマクロのみを使用する場合は、実行時に不要なパッケージのロードを停止するため、eval-when-compileを使用することをお勧めします。時間、メモリの節約とコードの高速化の両方。しかし、警告を避けるためだけに使用するのは、関数の誤用であるように思われます。そしてもちろん、clの関数のいずれかを使用したい場合は、とにかくeval-when-compileを使用することはできません。
[1]この変数にアクセスするには、.emacsファイルに(require'bytecomp)を追加する必要がある場合があります。
[2]理論的には、とにかく、しかしwith-no-warningsにはバグがあります。これは、字句変数に関するいくつかの警告を抑制しないことを意味します。
Common LISPには、elispとの名前空間の衝突がたくさんあります。多くの場合、関数は同じことをしているように見えますが、細部が少し異なります。 2つを混合することは、ユーザーの背後で行わないのが最善のリスクです。このため、cl.elのより便利な関数のほとんどはマクロとして定義されているため、cl.elはコンパイル時にのみ必要になり、マクロはEmacsの将来のセッションでそれらを使用するコードにのみ影響します。
私の前にコメントを読んだ後、私はこのメッセージを抑制することができませんでした。
しかし、私はGNU emacsメーリングリストの親切な人から次の指示を受けました。
Cl-libが必要です。次に、remove-if-notの代わりにcl-remove-if-notを使用するように呼び出しを変更します。
これが救済策であることが証明されました。
要約すると、 'cl-libを要求することにより、関数/マクロ呼び出しの名前も変更する必要があります。
HTH..。