npt-japanese

% Variable *FEATURES*

Variable FEATURES

Variable *FEATURES*

値の型

通常のリスト

初期値

実装依存

定義

*features*の値は、featuresリストと呼ばれます。これはシンボルのリストであり、featuresと呼ばれ、実装や環境のいくつかの状況に対応しています。

多くのfeaturesが実装依存の意味を持っています。下記の示すものは割り当てられたfeatureの名前です。

:cltl1
- この値が存在するとき、 LISPというパッケージが 1984年に制定されたCommon Lisp: The Languageに適合していることを示します。このfeatureをもつ適合する実装は、仕様に指定されたシンボルをLISPパッケージではなく COMMON-LISPパッケージ内にすることができますが、しかし必須ではありません。
:cltl2
- この値が存在するとき、実装はCommon Lisp: The Language, Second Editionに適合していることを示します。このfeatureは、どのような適合する実装にも存在してはいけません。なぜならそのドキュメントへの適合性はこの仕様の適合性と互換性がないからです。しかし、この名前はこの仕様書によって、プログラムがそのドキュメントの適合によって実装されたものとまたこの仕様書の適合によって実装されたものとの区別をする助けのために予約されています。
:ieee-floating-point
- この値が存在するとき、実装がIEEE Standard for Binary Floating-Point Arithmeticの要求に適合していることを示します。
:x3j13
- この値が存在するとき、実装がこの仕様書のドラフト版にあるいくつかの特定の要求に合致しているか、あるいは本仕様書に含まれる何らかのものについて、いくつかfeatureが含まれている部分があると信じられることを示します。適合した実装は、このようなfeatureを含むかもしれないし含まないかもしれません（このfeatureは、時期尚早に:draft-ansi-clや:ansi-clを導入しないように、ドラフト版の標準を利用可能にするための一時しのぎであることを主な目的としています）。
:draft-ansi-cl
- この値が存在するとき、実装は1992年に公式にレビューされた本仕様の最初のドラフト版全てについて適合していることを示します。適合した実装は、:draft-ansi-clのfeatureが含まれているときは、 :draft-ansi-cl-2か:ansi-clのfeature持つことは許されていません。なぜなら最初のドラフトと続くものは互換性が無い変更があるためです。
:draft-ansi-cl-2
- この値が存在するとき、実装は公式にレビューされた本仕様の2番目のドラフト版全てについて適合していることを示します（もし追加のドラフト版の公式レビューが導入されたとき、このキーワードは2番目のドラフトを意味するものであると続く、追加のキーワードが後のドラフト版の適合についての識別子として追加されます。そのようなものとして、このキーワードの意味は、時間経過とともに変更されることはありません）。適合した実装は、ansi-clのfeatureを持っているものについて、もし最終的に承認された標準がドラフト版の標準と非互換性ではないときに、だた:draft-ansi-clのfeatureのみを保持することが許されます。
:ansi-cl
- この値が存在するとき、実装はANSIによって採用された公式の標準である本仕様について適合していることを示します。
:common-lisp
- このfeatureは、 :x3j13, :draft-ansi-cl, :ansi-clのfeatureをひとつ以上保有するような実装においては *features*に現れなければなりません。これは:cltl1か:cltl2のfeatureを持つような実装についてもまた現れなければいけませんが、しかし本仕様書はそのようなふるまいを強制できません。このfeatureは「Common Lisp」という名前のファミリーの言語と、そうではなくそのファミリー内の何らかの仕様書における方言と区別するための同一性を持たせるという意味を持っています。

例文

なし。

影響

なし。

参考

1.5.2.1.1. リアルタイムコンディションの使用, 2.4. 標準マクロ文字

備考

*features*の値は、リーダー構文の#+と#-によって使用されます。

featuresリスト内のシンボルは、どのようなパッケージにもなれますが、実際にはそれらは一般的にKEYWORDパッケージになります。これは、 feature式を読み込むリーダーマクロの#+と#-が標準でKEYWORDパッケージを使用するためです。 featureの名前をパッケージP（KEYWORDではなく）で使用する必要があるコードは、 Pへのパッケージ前置詞を明に使うことで実現できますが、そのようなコードは readでfeature式を使うためにパッケージPが存在することを保証しなければならず、ある場合においてはfeature式の読み込みが失敗するかもしれません。

一般的に特定の実装で同一性を識別できるfeatureをひとつ以上含めることが実装にとってより良いと考えられます。そうすることにより条件式は他とは違うある実装の特異性として区別するような書き方ができるようになります。 featureは通常KEYWORDパッケージのシンボルであるため、結果として衝突が起こりやすく、また誰がどのシンボルをどのような理由で使用する権利を持っているかを決定する一意的なメカニズムがあるわけでもないので、保守的な戦略として自分の会社名や製品名から派生した名前を選択することができます。

TOP, Github

This site is open source. Improve this page.