Next: Backtracking, Previous: Instrumenting Macro Calls, Up: Edebug and Macros [Contents][Index]
あるマクロ呼び出しにおいて、いくつかの引数は評価されるが、それ以外の引数は評価されないような場合には、Edebug仕様のために仕様リスト(specification
list)が要求されます。仕様リスト内のいくつかの要素は1つ以上の引数にマッチしまづが、それ以外の要素は以降に続くすべての引数の処理を変更します。後者は仕様キーワード(specification
keywords)と呼ばれ、(&optionalのように)‘&’で始まるシンボルです。
仕様リストは、それ自身がリストであるような引数にマッチする部分リスト(sublist)、またはグループ化に使用されるベクターを含むかもしれません。したがって部分式とグループは、仕様リストをレベル階層に細分化します。仕様キーワードは、部分式やグループを含むものの残りに適用されます。
仕様リストに選択肢や繰り返しが含まれる場合は、実際のマクロの呼び出しにたいしてマッチさせるためにバックトラックが要求されるかもしれません。詳細は、Backtrackingを参照してください。
Edebug仕様は、バランスのとれたカッコで括られた部分式へのマッチ、フォームの再帰処理、インダイレクト仕様を通じた再帰などの、正規表現によるマッチングと、コンテキストに依存しない文法構成を提供します。
以下は仕様リストに使用できる要素と、その意味についてのテーブルです(使用例はSpecification Examplesを参照):
sexp評価れない単一のLispオブジェクト。インストルメントされない。
form評価される単一のLispオブジェクト。インストルメントされる。
place汎変数(generalized variable)。Generalized Variablesを参照。
body&rest formの省略形。以下の&restを参照。
function-form関数フォーム。クォートされた関数シンボル、クォートされたラムダ式、または(関数シンボルかラムダ式に評価される)フォームのうちのどれか。これはラムダ式のbodyをいずれかの方法でインストルメントするため、functionよりもquoteでクォートされたラムダ式の引数にたいし有用。
lambda-exprクォートされないラムダ式。
&optional仕様リスト内の後続の要素はオプション。マッチしない要素が出現すると、Edebugはこのレベルのマッチングを停止する。
後続が非オプションの要素であるような数個の要素をオプションにするだけなら、[&optional
specs…]を使用する。複数の要素すべてのマッチ、または非マッチを指定するには、&optional
[specs…]を使用する。defunの例を参照。
&rest仕様リスト内の後続のすべての要素は、0回以上繰り返される。しかし、最後の繰り返しでは、仕様リスト内のすべての要素にたいするマッチングの前に式が終了しても問題はない。
数個の要素を繰り返すには、[&rest
specs…]を使用する。各繰り返しにおいいてすべてマッチしなければならない複数要素を指定するには、&rest
[specs…]を使用する。
&or仕様リスト内の後続の各要素は選択肢。選択肢の1つがマッチしなければならず、マッチしない場合&or仕様は失敗する。
&orに続く各リスト要素は、単一の選択肢。複数のリスト要素を単一の選択肢にグループ化するには、それらを[…]で括る。
¬後続の各要素は、&orが使用されたときのように選択肢にマッチするが、要素がマッチした場合に失敗する。どれもマッチする要素がない場合は何もマッチされないが、¬仕様は成功する。
&defineフォーム定義にたいする仕様であることを示す。フォーム定義自体はインストルメントされない(つまりEdebugはフォーム定義の前後でストップしない)が、フォーム内部は通常はインストルメントされるであろう。&defineキーワードはリスト仕様の最初の要素であること。
nilカレント引数レベルでマッチさせる引数が存在しない場合は成功し、それ以外は失敗する。部分リスト仕様とバッククォートの例を参照。
gate引数はマッチされないがgateを通じたバックトラックは、このレベルの使用の残りをマッチングする間は無効にされる。これは主に、特定の構文エラーメッセージを一般的にするために使用される。詳細はBacktracking、およびletの例も参照。
other-symbol仕様リスト内のその他の要素は、述語(predicate)かインダイレクト仕様(indirect specification)である。
シンボルがEdebug仕様をもつ場合、インダイレクト仕様(indirect
specification)はシンボル位置に使用されるリスト仕様か、引数を処理するための関数のどちらかである。この仕様はマクロにたいするdef-edebug-specのように定義される。defunの例を参照。
それ以外の場合、シンボルは述語(predicate)である。述語は引数とともに呼び出され、述語がnilをリターンした場合、その仕様は失敗して引数はインストルメントされない。
適切な述語としてはsymbolp、integerp、stringp、vectorp、atomが含まれる。
[elements…]要素のベクターは、要素を単一のグループ仕様(group specification)にグループ化する。このグループ仕様は、ベクター自体に何も行わない。
"string"引数はstringという名前のシンボルである。この仕様は、symbolの名前がstringであるクォートされたシンボル'symbolと等価だが、文字列形式のほうが好ましい。
(vector elements…)引数は、要素が仕様内のelementsにマッチするベクターである。バッククォートの例を参照。
(elements…)他のリストは部分リスト仕様(sublist specification)であり、引数は要素が仕様のelementsにマッチするリストでなければならない。
部分リスト仕様はドットリスト(dotted
list)かもしれず、その場合対応するリスト引数はドットリストである。かわりに、ドットリスト仕様の最後のCDRが、(グループ化やインダイレクト仕様による)他の部分リスト仕様かもしれない(たとえば要素が非ドットリストにマッチする(spec
. [(more
specs…)])))。これはバッククォートの例のような再帰仕様に有用。このような再帰を終了させるには、上述のnil仕様も参照。
(specs . nil)のように記述された部分リスト仕様は(specs)、(specs .
(sublist-elements…))は(specs
sublist-elements…)と等価であることに注意。
以下は&defineの後だけに出現する追加仕様のリストです。defunの例を参照してください。
name引数(シンボル)は定義フォームの名前。
定義フォームは名前フィールドをもつ必要はなく、複数の名前フィールドをもつかもしれない。
:nameこの構成は引数に実際のマッチは行わない。:nameの後の要素はシンボルであり、その定義の追加の名前要素として使用される。定義名に一意で静的な要素を加えるために、これを使用できる。複数回使用されるかもしれない。
arg引数(シンボル)は定義フォームの引数の名前である。しかし、lambda-listキーワード(‘&’で始まるシンボル)は許されない。
lambda-listこれはラムダリスト(ラムダ式の引数リスト)にマッチする。
def-body引数は定義内のコードのbodyである。これは上述のbodyと似ているが、定義のbodyはその定義に関連する情報を照会する別のEdebug呼び出しでインストルメントされていなければならない。定義内のより高位レベルのフォームリストには、def-bodyを使用する。
def-form引数は、定義内のもっとも高位レベルの単一フォームである。これはdef-bodyと似ているが、フォームリストではなく単一フォームのマッチに使用される。特別なケースとして、def-formはフォームが実行されるときトレース情報を出力しないことも意味する。interactiveの例を参照。