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

コンピュータサイエンスにおいて、コンピュータ言語の構文とは、その言語で正しく構造化された文または表現であるとみなされる記号の組み合わせを定義する規則のことです。これは、文書がソースコードを表すプログラミング言語と、文書がデータを表す マークアップ言語の両方に適用されます。

言語の構文は言語の表面的な形式を定義します。^[1] テキストベースのコンピュータ言語は文字列に基づいていますが、ビジュアルプログラミング言語は空間的なレイアウトとシンボル間の接続に基づいています（シンボルはテキストまたはグラフィックです）。構文的に無効なドキュメントは構文エラーがあると言われています。言語の構文を設計する際、設計者は、これらの例から一般的なルールを理解しようとする前に、有効な文字列と無効な文字列の両方の例を書き出すことから始める場合があります。^[2]

したがって、構文はコードの形式を指し、意味であるセマンティクスとは対照的です。コンピュータ言語の処理では、セマンティクス処理は通常、構文処理の後に行われます。ただし、完全な構文解析にはセマンティクス処理が必要な場合があり、その場合はこれらが一緒にまたは同時に実行されます。コンパイラでは、構文解析はフロントエンドを構成し、セマンティクス解析はバックエンド（およびこのフェーズが区別されている場合はミドルエンド） を構成します。

コンピュータ言語の構文は、一般的に次の 3 つのレベルに区別されます。

• 単語 – 文字がどのようにトークンを形成するかを決定する語彙レベル。
• フレーズ – 狭義の文法レベルでは、トークンがどのようにフレーズを形成するかを決定します。
• コンテキスト - オブジェクトまたは変数名が何を参照しているか、型が有効かどうかなどを決定します。

このように区別することでモジュール性が生まれ、各レベルを個別に、多くの場合は独立して記述および処理できるようになります。

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

次に、パーサーはトークンの線形シーケンスを階層的な構文ツリーに変換します。これは、狭義では「構文解析」と呼ばれます。これにより、トークンの行がプログラミング言語の正式な文法に準拠していることが保証されます。構文解析段階自体は、2 つの部分に分けることができます。1 つは構文解析ツリー、つまり「具体的な構文ツリー」で、文法によって決定されますが、通常は実用には詳細すぎるものです。もう 1 つは抽象構文ツリー(AST) で、これはこれを使用可能な形式に簡略化します。AST とコンテキスト分析の手順は、構文に意味と解釈を追加するため、意味解析の一形態と見なすことができます。または、正式に記述または実装するのが困難または厄介な構文規則の非公式な手動実装と見なすことができます。

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

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

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

たとえば、(add 1 1)これは構文的に有効な Lisp プログラムです (「add」関数が存在すると仮定します。存在しない場合は名前解決が失敗します)。1 と 1 を加算します。ただし、次のプログラムは無効です。

(_ 1 1) 字句エラー: '_' は無効です
(1 1 解析エラーを追加: 閉じ ')' がありません

字句解析器は最初のエラーを識別できません。字句解析器が認識しているのは、トークン LEFT_PAREN, '(' を生成した後、単語規則が '_' で始まっていないため、プログラムの残りの部分は無効であるということです。2 番目のエラーは解析段階で検出されます。パーサーは、'(' トークン (唯一の一致として) により「リスト」生成規則を識別したため、エラー メッセージを表示できますが、一般にあいまいである可能性があります。

型エラーや未宣言変数エラーは、コンパイル時に検出された場合（通常は強く型付けされた言語をコンパイルする場合）には構文エラーと見なされることがあります。ただし、これらの種類のエラーは意味エラーとして分類されるのが一般的です。^{[4] [5] [6]}

例えば、Pythonコード

'あ' + 1

文字列リテラルを整数リテラルに追加しているため、型エラーが含まれています。この種の型エラーはコンパイル時に検出できます。コンパイラが「integerLiteral + integerLiteral」を許可するが「stringLiteral + integerLiteral」を許可しない別のルールを使用する場合、解析 (フレーズ分析) 中に検出できますが、コンパイラが「LiteralOrIdentifier + LiteralOrIdentifier」形式のすべての式を許可する解析ルールを使用する可能性が高く、その場合はコンテキスト分析 (型チェックが行われるとき) 中にエラーが検出されます。場合によっては、この検証がコンパイラによって行われず、これらのエラーは実行時にのみ検出されます。

動的型付け言語では、型は実行時にのみ決定され、多くの型エラーは実行時にのみ検出されます。たとえば、Pythonコード

a + b

はフレーズレベルでは構文的に有効ですが、Python では変数に型がなく、値にのみ型があるため、a と b の型の正しさは実行時にのみ判断できます。コンパイラによって検出された型エラーを構文エラー (静的な意味エラーではなく) と呼ぶべきかどうかについては意見の相違がありますが、プログラム実行時にのみ検出できる型エラーは、常に構文エラーではなく意味エラーと見なされます。

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

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

言語には、同等の正規表現 (語彙レベル) などの異なる同等の文法や、同じ言語を生成する異なるフレーズ ルールが存在する場合があります。LR 文法などのより広いカテゴリの文法を使用すると、より制限されたカテゴリ (LL 文法など) と比較して、より短いまたは単純な文法を使用できます。LL 文法では、より多くのルールを持つ長い文法が必要になる場合があります。異なるが同等のフレーズ文法は、基礎となる言語 (有効なドキュメントのセット) は同じですが、異なる解析ツリーを生成します。

以下は、正規表現の表記法と拡張バッカス・ナウア記法を使用して定義された簡単な文法です。これは、プログラミング言語Lispのデータ構文であるS 式の構文を記述したもので、構文カテゴリ式、アトム、数値、シンボル、リストの生成規則を定義します。

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

この文法では次のことを指定します。

• 式はアトムまたはリストのいずれかです。
• 原子は数字か記号のいずれかです。
• 数値は、1 つ以上の 10 進数字の連続であり、オプションでプラス記号またはマイナス記号が前に付きます。
• シンボルは文字の後に0個以上の任意の文字（空白を除く）が続くものです。
• リストは、内部に0 個以上の式が含まれる、対応する括弧のペアです。

ここでは、小数点、大文字と小文字、および括弧が終端記号です。

以下は、この文法における適切なトークンシーケンスの例です: ' 12345'、' ()'、' (A B C232 (1))'

プログラミング言語を指定するために必要な文法は、チョムスキー階層における位置によって分類できます。ほとんどのプログラミング言語の句文法は、タイプ2文法、つまり文脈自由文法を使用して指定できますが、^[8]全体的な構文は文脈依存（変数宣言とネストされたスコープのため）であるため、タイプ1です。ただし、例外もあり、一部の言語では句文法はタイプ0（チューリング完全）です。

Perl や Lisp などの一部の言語では、言語の仕様 (または実装) によって構文解析フェーズ中に実行される構造が許可されています。さらに、これらの言語には、プログラマがパーサーの動作を変更できる構造があります。この組み合わせにより、構文解析と実行の区別が実質的にあいまいになり、これらの言語での構文解析が決定不能な問題になり、構文解析フェーズが終了しない可能性があります。たとえば、Perl ではBEGIN、ステートメントを使用して構文解析中にコードを実行できます。また、Perl 関数プロトタイプによって構文解釈が変更され、残りのコードの構文の妥当性さえも変更される可能性があります。^{[9] [10]}口語的には、これは「Perl だけが Perl を解析できる」(構文解析中にコードを実行する必要があり、文法を変更できるため)、またはより強く「Perl でさえ Perl を解析できない」(決定不能であるため) と呼ばれます。同様に、構文によって導入されたLispマクロdefmacroも解析中に実行されるため、LispコンパイラにはLispランタイムシステム全体が存在する必要がある。対照的に、Cマクロは単なる文字列の置換であり、コードの実行を必要としない。^{[11] [12]}

言語の構文は有効なプログラムの形式を記述しますが、プログラムの意味やそのプログラムを実行した結果についての情報は提供しません。記号の組み合わせに与えられた意味は、セマンティクス（形式的または参照実装でハードコードされている）によって処理されます。セマンティクスが意味を成すためには、まず有効な構文が確立されていなければなりません。^[7]構文的に正しいプログラムのすべてが意味的に正しいわけではありません。多くの構文的に正しいプログラムは、言語のルールによれば不適切であり、（言語仕様と実装の健全性に応じて）翻訳または実行時にエラーが発生する可能性があります。場合によっては、そのようなプログラムは未定義の動作を示すことがあります。プログラムが言語内で適切に定義されている場合でも、それを書いた人が意図していない意味を持つことがあります。

自然言語を例に挙げると、文法的に正しい文に意味を割り当てることができない場合や、文が間違っている場合があります。

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

次の C 言語のフラグメントは構文的には正しいですが、意味的に定義されていない操作を実行します (はnull ポインターpなので、操作と は意味を持ちません)。 p->realp->im

 複素数* p = NULL ;複素数abs_p = sqrt ( p -> real * p -> real + p -> im * p -> im );   
           

もっと簡単な例として、

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

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

• 命名規則（プログラミング）
• プログラミング言語の比較（構文）

さまざまなプログラミング言語の構文を簡単に比較するには、 「Hello, World!」プログラム例のリストをご覧ください。

• Prologの構文と意味論
• Perl構文
• PHP の構文とセマンティクス
• C構文
• C++構文
• Java構文
• JavaScript 構文
• Pythonの構文とセマンティクス
• Lua構文
• Haskell構文

• コンピュータプログラミング言語で使用されるさまざまな構文構造
• Python エラー「ImportError: モジュール名がありません」なぜですか? 方法は? コマンドライン? [解決済み 2021]