構文（プログラミング言語）

コンピュータソースコードの構文は、コンピュータ言語の規則に従って構造化され、順序付けられたコードです。自然言語と同様に、コンピュータ言語（つまりプログラミング言語）は、その言語で有効な構文を定義します。 ^{[ 1 ]}構文エラーは、コンパイラやインタプリタなどのツールによって構文的に無効なソースコードが処理されたときに発生します。

最も一般的に使用されている言語は、文字列に基づいた構文を持つテキストベースの言語です。一方、ビジュアルプログラミング言語の構文は、グラフィック要素間の関係に基づいています。

構文を設計する際、どの言語の設計者も、まず有効な文字列と無効な文字列の両方の例を書き出し、それらの例から一般的な規則を見つけ出そうとするかもしれません。構文の一般的な構造は、その構成形式によって決定され、考えられるすべての変更に対して常に意味的に有効な範囲が生成されます。そうでない場合は、無効な入力ごとにエラーと警告が返されます。^{[ 2 ]}

コンピュータ言語の構文は、一般的に3つのレベルに分けられます。

• 単語 – 語彙レベルであり、文字がどのようにトークンを形成するかを決定する。
• 句 ― 狭義には、文法レベルにおいて、トークンがどのように句を形成するかを決定するもの。
• コンテキスト – オブジェクトや変数名が何を指しているのか、型が有効かどうかなどを判断する。

このように区別することでモジュール化が実現し、各レベルを個別に、そして多くの場合独立して記述および処理することが可能になる。

まず、字句解析器は文字の線形シーケンスをトークンの線形シーケンスに変換します。これは「字句解析」または「字句解析」として知られています。^{[ 3 ]}

第二に、パーサーはトークンの線形シーケンスを階層的な構文木に変換します。これは狭義には「構文解析」と呼ばれます。これにより、トークンの行がプログラミング言語の形式文法に準拠することが保証されます。構文解析段階自体は、2つの部分に分けられます。1つは構文木、または「具体的な構文木」で、これは文法によって決定されますが、一般的に実用には詳細すぎます。もう1つは抽象構文木（AST）で、これはこれを使いやすい形式に簡略化します。ASTと文脈分析のステップは、構文に意味と解釈を追加するため、意味解析の一形態と考えることができます。あるいは、形式的に記述または実装するのが困難または不便な構文規則の非公式な手動実装と考えることもできます。

第三に、文脈解析は名前を解決し、型をチェックします。このようなモジュール性は可能な場合もありますが、多くの実際の言語では、前のステップが後のステップに依存しています。例えば、C言語の字句解析器のハックは、トークン化が文脈に依存しているためです。このような場合でも、構文解析はしばしばこの理想的なモデルを近似するものと見なされます。

レベルは一般的にチョムスキー階層のレベルに対応しています。単語は、通常、正規表現で与えられるタイプ 3 文法である語彙文法で指定される正規言語です。句は、通常、バッカス・ナウア記法 (BNF) の生成規則で与えられるタイプ 2 文法である句構造文法で指定される、通常、決定論的文脈自由言語 (DCFL) である文脈自由言語( CFL ) です。句文法は、解析を容易にするために、完全な文脈自由文法よりもはるかに制約の多い文法で指定されることがよくあります。LRパーサーは任意の DCFL を線形時間で解析できますが、単純なLALR パーサーやさらに単純なLL パーサーはより効率的ですが、生成規則が制約されている文法しか解析できません。原則として、文脈構造は文脈依存文法によって記述でき、属性文法などの手段によって自動的に分析できますが、一般的にはこの手順は名前解決ルールと型チェックを介して手動で行われ、各スコープの名前と型を格納するシンボルテーブルによって実装されます。

正規表現で記述された字句仕様から字句解析器を、BNFで記述された句文法から構文解析器を自動的に生成するツールが作成されています。これにより、手続き型プログラミングや関数型プログラミングではなく、宣言型プログラミングを使用できます。注目すべき例として、lex - yacc のペアがあります。これらは具体的な構文木を自動的に生成しますが、構文解析器の作成者は、これを抽象構文木に変換する方法を記述するコードを手動で記述する必要があります。文脈解析も一般的に手動で実装されます。これらの自動ツールが存在するにもかかわらず、構文解析はさまざまな理由で手動で実装されることがよくあります。たとえば、句構造が文脈自由ではない場合、代替実装によってパフォーマンスやエラー報告が改善される場合、または文法をより簡単に変更できる場合などです。構文解析器は、Haskellなどの関数型プログラミング言語、 PythonやPerlなどのスクリプト言語、またはCやC++などの命令型プログラミング言語で記述されることがよくあります。

テキストベースのプログラミング言語の構文は通常、正規表現（字句構造用）とバッカス・ナウア記法（文法構造用のメタ言語）を組み合わせて、構文カテゴリ（非終端記号）と終端記号を帰納的に指定することによって定義されます。^{[ 4 ]}構文カテゴリは、特定の構文カテゴリに属する​​値を指定するプロダクションと呼ばれる規則によって定義されます。 ^{[ 1 ]}終端記号は、構文的に有効なプログラムが構築される具体的な文字または文字列（例えば、 define、if、let、voidなどのキーワード）です。

構文は、文脈自由構文と文脈依存構文に分けられます。^{[ 4 ]}文脈自由構文は、プログラミング言語のメタ言語によって指示される規則です。これらは、構文のその部分を取り囲む、または参照する文脈によって制約されませんが、文脈依存構文は制約されます。

言語には、同等の正規表現（語彙レベル）や、同じ言語を生成する異なる句規則など、複数の同等の文法が存在する可能性があります。LR文法のようなより広いカテゴリの文法を使用すると、LL文法のようなより限定的なカテゴリと比較して、より短く単純な文法で済む場合があります。LL文法では、より多くの規則を持つより長い文法が必要になる可能性があります。異なるが同等の句文法は、基となる言語（有効な文書の集合）は同じであっても、異なる構文解析木を生成します。

式=原子 |リスト原子 =数値|シンボル 数値 = [ + - ] ? [ '0' - '9' ] +シンボル = [ 'A' - 'Z' ][ 'A' - 'Z''0' - '9' ]. *リスト = '(' ,式* , ')'

言語の構文は有効なプログラムの形式を記述しますが、プログラムの意味や実行結果に関する情報は提供しません。記号の組み合わせに与えられる意味は、意味論（形式的か参照実装にハードコーディングされているかのいずれか）によって処理されます。意味論が意味を付与するには、有効な構文が確立されている必要があります。^{[ 4 ]}構文的に正しいプログラムがすべて意味的に正しいとは限りません。構文的に正しいプログラムの多くは、言語の規則に従って不完全な形式であり、（言語仕様と実装の健全性によっては）翻訳または実行時にエラーが発生する可能性があります。場合によっては、そのようなプログラムは未定義の動作を示す可能性があります。プログラムが言語内で適切に定義されている場合でも、それを書いた人が意図していない意味を持つ可能性があります。

自然言語を例にとると、文法的に正しい文であっても意味を付与できない場合や、文自体が誤っている場合がある。

• 「無色の緑のアイデアは激しく眠る。」は文法的には正しいが、一般的に受け入れられている意味はない。
• 「ジョンは既婚の独身男性です。」は文法的には正しいが、真実ではあり得ない意味を表している。

以下のC言語の断片は構文的には正しいが、意味的に定義されていない操作を実行している（はヌルポインタpであるため、操作および は意味を持たない）。p->realp->im

complex * p = NULL ; complex abs_p = sqrt ( p -> real * p -> real + p -> im * p -> im );

より簡単な例として、

int x ; printf ( "%d" , x );

は構文的には有効ですが、初期化されていない変数を使用しているため、意味的には定義されていません。一部のプログラミング言語（JavaやC#など）のコンパイラは、このような初期化されていない変数のエラーを検出しますが、これらは構文エラーではなく意味エラーとみなされるべきです。 ^{[ 10 ] [ 11 ]}

• コンピュータプログラミング言語で使用されるさまざまな構文構造
• Pythonエラー「ImportError: No module named」なぜ？どうすれば？コマンドライン？[解決済み2021]。 2021年10月9日にWayback Machineにアーカイブされました。