ガイドライン

以下は，Notation パッケージの使用中，および／または表記法の作成中に発生する可能性がある問題と検討事項である．

表記法を段階的に作成する

目に見えないものをデバッグするのは困難である．従って，表記法を作成し，それが動作しているか，間違いがないかを見るのが最もよい方法である．テストしないで複雑な表記法のすべてを入力すると，誤りを見付けるのが難しくなる．通常，表記法に関する問題の多くは，式の完全形を確認したり，eでその内部構造を調べたりすることにより明らかになる．

変更しすぎない

変更し過ぎないように注意されたい．例えば，コンマは縦棒に変更するなどは避けるべきである．形の中で異常な表記がより多く存在すれば，それだけ1つの表記法が他の表記法に悪影響を及ぼして意外な結果が生じる危険性も高まる．構文解析法によっては指定の文法におけるコンフリクトを検出するメカニズムを備えていることもあるが，Notation パッケージにはない．

できる限り既存の慣習に従う

可能な限り，Mathematica の標準の慣習や，その分野の慣習に従うべきである．独自の非標準的な表記法は，他のユーザが認識できないためお勧めしない．たとえ歴史的な起源がある表記法が，他の著者が考えうる表記法と比べて直観的でなかったとしても，できる限り歴史的な表記法を使う方がよいだろう．しかし，表記法によっては，存在する矛盾を解決するのが難しく，一貫した表記法が望まれる場合もあることも否めない．

可能な限り評価せずに構文解釈する

表記法の作成の際は，式を評価せずに正しい完全形に構文解釈できることが望ましい．これは外部形式と内部形式が一対一で対応しない複雑な表記法では不可能なこともある．しかし，可能な場合は，評価による2次的な作用はない．

次の表記法は正しく動作するために評価に依存しない．

望ましくない評価の一般的な例として，複雑なパターンとタグNotationPatternTagで使われているテスト関数がある．可能なら，テスト関数がその引数を維持するように設計すべきである．

関数StringNumericQを使って定義された表記法は引数を評価する．そのため，結果は予期できないものとなる．

構造が異なる内部表記と外部表記

従来の表記法がMathematica での内部構造に簡単には一致しない場合は，表記法が内部Mathematica 名の従来の形式に「Typeset」が後置した形を取るようにすることをお勧めする．例えば，MeijerG関数は次のTraditionalFormでなければならない．

しかしMathematica におけるMeijerG関数のFullFormは次の形式である．

従って，，，，がMeijerG関数の内部形式を構築することができるようになる前に，これらが正しい値をもつ数であることを確認しなければならない．従来の形式から内部形式へ評価せずに変換することはできない．

そのため，この場合は従来のMeijerGボックス形式をMeijerGTypeset[{{,},{,}},{,...,},{,...,}}]としなければならない．その後，構築が可能になったら評価して内部MeijerG関数にする．

また，別の可能性として，定義された「テンソル」をGridBoxを用いて式TensorTypesetにするというものがある．構造が有効である，つまりテンソルが同じ列内に反変および共変指数を持つなどの場合は，これを評価すると内部形式「Tensor」になる．

Jason Harris (jasonh@wolfram.com), April 2003.