[インデックス 1901] ファイルの概要

このコミットは、Go言語の公式仕様書である doc/go_spec.html における複合リテラル（Composite Literal）の記述を修正し、用語の整合性を高めるものです。具体的には、複合リテラル内で使用される「ペア」に関する用語を、抽象構文木（AST）のノード名と一致させるために PairExpr を KeyValueExpr に、PairExprList を KeyValueList にそれぞれ変更しています。また、複合リテラルの評価順序に関するTODOコメントが追加されています。

コミット

- minor tweak to composite literal production:
renamed PairExpr -> KeyValueExpr and PairExprList -> KeyValueList
(to match corresponding nodes in AST per rsc' suggestion)

- added a couple of TODOs

R=r,rsc
DELTA=10  (2 added, 0 deleted, 8 changed)
OCL=26837
CL=26840

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/c5c577c1ff19f7398c9c97755d6cfdbe73df53b6

元コミット内容

commit c5c577c1ff19f7398c9c97755d6cfdbe73df53b6
Author: Robert Griesemer <gri@golang.org>
Date:   Fri Mar 27 13:43:28 2009 -0700

    - minor tweak to composite literal production:
    renamed PairExpr -> KeyValueExpr and PairExprList -> KeyValueList
    (to match corresponding nodes in AST per rsc' suggestion)
    
    - added a couple of TODOs
    
    R=r,rsc
    DELTA=10  (2 added, 0 deleted, 8 changed)
    OCL=26837
    CL=26840
---\n doc/go_spec.html | 12 +++++++-----\n 1 file changed, 7 insertions(+), 5 deletions(-)\n\ndiff --git a/doc/go_spec.html b/doc/go_spec.html\nindex ad98b8355a..e90f605605 100644\n--- a/doc/go_spec.html\n+++ b/doc/go_spec.html\n@@ -25,15 +25,15 @@ Todo\'s:\n [ ] fix \"else\" part of if statement\n [ ] cleanup: 6g allows: interface { f F } where F is a function type.\n \tfine, but then we should also allow: func f F {}, where F is a function type.\n-\n+[ ] decide if and what to write about evaluation order of tuple assignments\n+[ ] decide if and what to write about evaluation order of composite literal\n+    elements (single expressions, (key:value) pairs)\n \n Wish list:\n [ ] enum facility (enum symbols that are not mixable with ints) or some other\n@@ -1885,15 +1887,15 @@ Composite literals construct values for structs, arrays, slices, and maps\n and create a new value each time they are evaluated.\n They consist of the type of the value\n followed by a brace-bound list of expressions,\n-or a list of expression pairs for map literals.\n+or a list of key-value pairs for map literals.\n </p>\n \n <pre class=\"grammar\">\n-CompositeLit  = LiteralType \"{\" [ ( ExpressionList | ExprPairList ) [ \",\" ] ] \"}\" .\n+CompositeLit  = LiteralType \"{\" [ ( ExpressionList | KeyValueList ) [ \",\" ] ] \"}\" .\n LiteralType   = StructType | ArrayType | \"[\" \"...\" \"]\" ElementType |\n                 SliceType | MapType | TypeName .\n-ExprPairList  = ExprPair { \",\" ExprPair } .\n-ExprPair      = Expression \":\" Expression .\n+KeyValueList  = KeyValueExpr { \",\" KeyValueExpr } .\n+KeyValueExpr  = Expression \":\" Expression .\n </pre>\n \n <p>\n```

## 変更の背景

このコミットの主な背景は、Go言語の仕様書における用語と、コンパイラが内部的に使用する抽象構文木（AST）の用語との整合性を図ることにあります。Go言語の設計初期段階において、言語仕様の記述と実際のコンパイラ実装との間で用語の統一が図られていました。

コミットメッセージにある「rsc' suggestion」（rscの提案）は、Go言語の主要な開発者の一人であるRuss Cox氏の提案を指しています。彼はGo言語の設計と実装において中心的な役割を担っており、彼の提案は言語の整合性と品質向上に大きく貢献しています。

複合リテラル、特にマップリテラルにおいて、要素は「キーと値のペア」として構成されます。この実態をより正確に反映し、かつコンパイラが生成するASTのノード名（`KeyValueExpr`など）と一致させることで、仕様の明確性と実装との一貫性を高めることが目的でした。

また、追加されたTODOコメントは、Go言語の仕様がまだ発展途上にあり、特に複合リテラルや多重代入における評価順序といった、言語のセマンティクスに関する重要な詳細が検討中であったことを示しています。これらの評価順序は、プログラムの挙動の予測可能性と正確性を保証するために極めて重要です。

## 前提知識の解説

### Go言語の複合リテラル (Composite Literal)

Go言語における複合リテラルは、構造体（struct）、配列（array）、スライス（slice）、マップ（map）といった複合型の値を簡潔に初期化するための構文です。これらは、型名の後に波括弧 `{}` で囲まれた要素のリストを記述することで作成されます。

*   **構造体リテラル**: `Point{X: 1, Y: 2}` のように、フィールド名と値のペアで初期化します。
*   **配列・スライスリテラル**: `[]int{1, 2, 3}` のように、要素のリストで初期化します。配列の場合は `[...]int{1, 2, 3}` のように要素数も指定できます。
*   **マップリテラル**: `map[string]int{"a": 1, "b": 2}` のように、キーと値のペアで初期化します。

複合リテラルは、コードの可読性を高め、新しい値の生成と初期化を同時に行う便利な方法を提供します。

### 抽象構文木 (Abstract Syntax Tree - AST)

抽象構文木（AST）は、プログラミング言語のソースコードの抽象的な構文構造を木構造で表現したものです。コンパイラやインタプリタがソースコードを解析する際に、字句解析（トークン化）と構文解析（パース）の後に生成されます。

ASTは、プログラムの構造を階層的に表現し、各ノードがコード内の構成要素（変数、演算子、関数呼び出し、リテラルなど）に対応します。コンパイラはASTを利用して、意味解析（型チェックなど）、最適化、そして最終的な機械語コードの生成を行います。Go言語では、標準ライブラリの `go/ast` パッケージを通じてASTをプログラム的に操作することが可能です。

### Go言語の仕様 (Go Specification)

Go言語の仕様は、Go言語の文法、セマンティクス、標準ライブラリの動作などを厳密に定義した公式ドキュメントです。Go言語の設計思想と挙動の根幹をなすものであり、コンパイラの実装やGoプログラムの動作はすべてこの仕様に準拠しています。このコミットで変更された `doc/go_spec.html` は、この公式仕様書の一部です。

### Russ Cox (rsc)

Russ Coxは、Go言語の初期からの主要な開発者の一人であり、Goチームのテクニカルリードを長年務めました。彼はGo言語の設計、特にモジュールシステムやツールチェイン、パフォーマンス最適化など、多岐にわたる分野で重要な貢献をしてきました。彼の提案やレビューは、Go言語の安定性、効率性、そして使いやすさに大きく影響を与えています。

### 早期のGo言語開発

このコミットは2009年3月のものであり、Go言語が一般に公開されたのが2009年11月であることを考えると、Go言語がまだ活発に開発され、その仕様が固まっていく非常に初期の段階であったことを示しています。この時期には、言語の文法、セマンティクス、標準ライブラリの設計など、多くの議論と変更が頻繁に行われていました。用語の統一や仕様の明確化は、この時期の重要な作業の一つでした。

## 技術的詳細

このコミットの技術的詳細は、Go言語の仕様書における複合リテラルの文法定義の厳密化と、それに伴う用語の変更に集約されます。

Go言語の複合リテラルは、構造体、配列、スライス、マップの初期化に使用されます。特にマップリテラルでは、`key: value` の形式で要素を記述します。この `key: value` の組は、まさに「キーと値のペア」であり、この実態を文法定義の用語に反映させることが変更の核心です。

変更前は、マップリテラルの要素のリストを `ExprPairList`（式ペアのリスト）、個々の要素を `ExprPair`（式ペア）と呼んでいました。しかし、Goコンパイラが内部的にソースコードを解析して生成するASTでは、これらの構造は `KeyValueList` や `KeyValueExpr` といったノードで表現されていました。

このコミットでは、仕様書内の文法定義を以下のように変更しました。

*   `ExprPairList` を `KeyValueList` に変更
*   `ExprPair` を `KeyValueExpr` に変更

これにより、Go言語の仕様書とコンパイラの内部表現（AST）との間で用語の整合性が確保され、言語の記述が一貫したものになりました。これは、言語の設計者、実装者、そしてユーザーにとって、より明確で理解しやすい仕様を提供するために重要なステップです。

また、追加されたTODOコメントは、複合リテラルや多重代入における要素の評価順序に関する未解決の設計課題を示しています。例えば、`map[string]int{"a": f(), "b": g()}` のようなマップリテラルにおいて、`f()` と `g()` のどちらが先に評価されるか、あるいは並行して評価されるかといった挙動は、言語のセマンティクスにおいて非常に重要です。これらの評価順序が明確に定義されていないと、プログラムの挙動が予測不能になったり、異なるコンパイラ実装間で挙動が異なったりする可能性があります。このTODOは、Go言語が厳密な仕様を構築していく過程で、このような細部まで考慮されていたことを示しています。

## コアとなるコードの変更箇所

変更は `doc/go_spec.html` ファイル内で行われました。

```diff
--- a/doc/go_spec.html
+++ b/doc/go_spec.html
@@ -25,15 +25,15 @@ Todo\'s:
 [ ] fix \"else\" part of if statement
 [ ] cleanup: 6g allows: interface { f F } where F is a function type.
 \tfine, but then we should also allow: func f F {}, where F is a function type.
-\n+[ ] decide if and what to write about evaluation order of tuple assignments
+[ ] decide if and what to write about evaluation order of composite literal
+    elements (single expressions, (key:value) pairs)\n
 Wish list:\n [ ] enum facility (enum symbols that are not mixable with ints) or some other\n@@ -1885,15 +1887,15 @@ Composite literals construct values for structs, arrays, slices, and maps\n and create a new value each time they are evaluated.\n They consist of the type of the value\n followed by a brace-bound list of expressions,\n-or a list of expression pairs for map literals.\n+or a list of key-value pairs for map literals.\n </p>\n \n <pre class=\"grammar\">\n-CompositeLit  = LiteralType \"{\" [ ( ExpressionList | ExprPairList ) [ \",\" ] ] \"}\" .\n+CompositeLit  = LiteralType \"{\" [ ( ExpressionList | KeyValueList ) [ \",\" ] ] \"}\" .\n LiteralType   = StructType | ArrayType | \"[\" \"...\" \"]\" ElementType |\n                 SliceType | MapType | TypeName .\n-ExprPairList  = ExprPair { \",\" ExprPair } .\n-ExprPair      = Expression \":\" Expression .\n+KeyValueList  = KeyValueExpr { \",\" KeyValueExpr } .\n+KeyValueExpr  = Expression \":\" Expression .\n </pre>\n \n <p>\n```

具体的には、以下の行が変更されました。

1.  **TODOコメントの追加**:
    *   `[ ] decide if and what to write about evaluation order of tuple assignments`
    *   `[ ] decide if and what to write about evaluation order of composite literal elements (single expressions, (key:value) pairs)`

2.  **複合リテラルの説明文の変更**:
    *   `- or a list of expression pairs for map literals.`
    *   `+ or a list of key-value pairs for map literals.`

3.  **文法定義の変更**:
    *   `CompositeLit = LiteralType "{" [ ( ExpressionList | ExprPairList ) [ "," ] ] "}" .`
        *   `ExprPairList` が `KeyValueList` に変更。
    *   `ExprPairList = ExprPair { "," ExprPair } .`
        *   `ExprPairList` が `KeyValueList` に変更。
    *   `ExprPair = Expression ":" Expression .`
        *   `ExprPair` が `KeyValueExpr` に変更。

## コアとなるコードの解説

このコミットにおけるコアとなるコードの変更は、Go言語の文法定義をより正確で一貫性のあるものにするためのものです。

*   **TODOコメントの追加**:
    Go言語の仕様策定において、複合リテラルや多重代入の評価順序は、プログラムの予測可能な挙動を保証するために非常に重要な側面です。これらのTODOコメントは、言語設計者がこれらの詳細について深く検討し、将来的に仕様に明記する必要があると考えていたことを示しています。評価順序は、副作用を持つ式（例えば関数呼び出し）がリテラル内で使用された場合に、その副作用がいつ発生するかを決定するため、言語のセマンティクスにおいて不可欠な要素です。

*   **説明文の変更**:
    `"expression pairs"` から `"key-value pairs"` への変更は、マップリテラルの要素が単なる式のペアではなく、明確に「キー」と「値」という役割を持つことを強調しています。これは、Go言語のマップの概念をより直感的に反映した表現です。

*   **文法定義の変更**:
    *   `ExprPairList` から `KeyValueList` への変更:
        これは、複合リテラル、特にマップリテラル内の要素のリストが、単なる「式のペアのリスト」ではなく、「キーと値のペアのリスト」であることを明確に示しています。これにより、文法定義がより意味論的に正確になります。
    *   `ExprPair` から `KeyValueExpr` への変更:
        これは、個々の `key: value` の構造が、単なる「式のペア」ではなく、「キーと値の式」であることを示しています。GoコンパイラのASTでは、この構造は `ast.KeyValueExpr` として表現されるため、仕様書とASTの用語が一致し、言語の内部構造と外部仕様の整合性が高まります。

これらの変更は、Go言語の仕様が初期段階から厳密に定義され、内部実装との整合性が重視されていたことを示しています。これにより、Go言語の学習者やツール開発者にとって、より明確で理解しやすい言語仕様が提供されることになります。

## 関連リンク

*   Go言語の公式ウェブサイト: https://go.dev/
*   Go言語の仕様書: https://go.dev/ref/spec

## 参考にした情報源リンク

*   Go言語の早期開発の歴史に関する情報 (Web検索結果より)
*   Go言語の複合リテラルとASTに関する情報 (Web検索結果より)
*   Russ Cox氏のGo言語への貢献に関する情報 (Web検索結果より)
*   Go言語の公式ドキュメント (doc/go_spec.html)
*   Go言語のソースコードリポジトリ (GitHub)