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

このコミットは、Go言語の初期開発段階において、コンパイラ（6g）が受け入れる構文と、コード整形ツール（"pretty printer"）が期待する構文との間に存在した不整合を修正するものです。具体的には、import文におけるセミコロンの有無に関する構文エラーを解消し、コードベースの一貫性を保つことを目的としています。

コミット

コミットハッシュ: e9741e7dbd241c53e53dfb29292030e4393a473b
作者: Robert Griesemer gri@golang.org
コミット日時: 2008年12月16日火曜日 18:08:16 -0800
変更ファイル: usr/gri/pretty/universe.go
変更概要: import文の構文エラーを修正（6gコンパイラでは受け入れられたが、pretty printerでは受け入れられなかった構文）。

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

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

元コミット内容

fix syntax error (syntax accepted by 6g, but not by pretty printer)

R=r
OCL=21385
CL=21385

変更の背景

このコミットは、Go言語がまだ一般に公開される前の、非常に初期の開発段階（2008年12月）に行われたものです。当時のGo言語には、複数のコンパイラ（例: 6g）と、コードの自動整形を行うためのツール（"pretty printer"、後のgofmtの原型）が存在していました。

変更の背景には、以下の問題がありました。

構文の不整合: 6gコンパイラは特定のimport文の構文（この場合はセミコロンがない形式）をエラーなく処理できましたが、同じコードを整形しようとする"pretty printer"はそれを構文エラーと認識し、正しく整形できませんでした。
開発初期の揺らぎ: 言語仕様が固まりきっていない開発初期段階では、コンパイラやツール間で構文解釈に差異が生じることは珍しくありません。このような不整合は、開発者が一貫したコードスタイルを維持し、ツールチェーン全体でスムーズな開発体験を得る上で障害となります。
コード品質と一貫性: Go言語は、その設計思想として「一貫性のあるコードスタイル」を重視しており、gofmtのような自動整形ツールはその中心的な役割を担っています。このコミットは、その初期段階からコードの整形と構文の一貫性を確保しようとする取り組みの一環と見なせます。

この修正は、コンパイラと整形ツールの両方が同じ構文規則に従うように調整し、開発ワークフローの円滑化を図るための重要なステップでした。

前提知識の解説

Go言語の初期開発

Go言語は、GoogleのRobert Griesemer、Rob Pike、Ken Thompsonによって2007年9月に設計が開始され、2008年には初期のコンパイラ開発が進行していました。このコミットが行われた2008年12月は、Go言語がまだ一般に公開される前の、活発な内部開発フェーズにありました。言語仕様やツールチェーンが日々進化し、安定化に向けて試行錯誤が繰り返されていた時期です。

6gは、Go言語の初期に存在したコンパイラの一つです。当時のGoコンパイラは、ターゲットとするCPUアーキテクチャに応じて異なる名前が付けられていました。例えば、6gはamd64アーキテクチャ向け、8gは386アーキテクチャ向け、5gはarmアーキテクチャ向けでした。これらのコンパイラは、Go言語のソースコードを機械語に変換する役割を担っていました。Go 1.5以降では、これらのアーキテクチャ固有のコンパイラはgo tool compileコマンドに統合され、直接6gという名前で呼び出すことはなくなりました。

Pretty Printer (整形ツール)

"Pretty printer"とは、ソースコードを読みやすく、一貫性のあるスタイルに自動的に整形するツールの総称です。Go言語においては、gofmtがその代表的なツールであり、Goのコードスタイルを統一する上で極めて重要な役割を果たしています。gofmtは、インデント、スペース、改行、セミコロンの自動挿入（または削除）など、様々な整形ルールを適用します。このコミットで言及されている"pretty printer"は、gofmtの初期バージョンまたはその開発中のプロトタイプであったと考えられます。Go言語の設計哲学の一つに「コードの見た目を統一する」というものがあり、gofmtはその思想を具現化したものです。

構文解析と整形における差異

プログラミング言語のコンパイラやインタプリタは、ソースコードを解析してその意味を理解し、実行可能な形式に変換します。一方、コード整形ツールは、ソースコードの構造を解析し、特定のスタイルガイドラインに従って再フォーマットします。これらのツールは同じ言語の構文を扱いますが、その解釈や許容範囲に微妙な差異が生じることがあります。特に言語の初期段階では、仕様が完全に固まっていないため、コンパイラが許容する「緩い」構文が、整形ツールでは「厳密な」構文エラーとして扱われることがあります。これは、コンパイラがコードを実行可能にするための最低限の要件を満たせばよいのに対し、整形ツールは特定のスタイルルールを厳格に適用しようとするためです。

技術的詳細

このコミットの技術的詳細は、Go言語のimport文の構文と、セミコロンの扱いに関するものです。

Go言語では、通常、文の終わりを示すセミコロン（;）は省略可能です。コンパイラは、改行を文の区切りとして自動的に解釈します（Automatic Semicolon Insertion）。しかし、特定の文脈や、言語の初期実装においては、このルールが完全に適用されていなかったり、ツール間で解釈が異なったりすることがありました。

問題の箇所は、importブロック内の"array"パッケージのインポート文です。

元のコード:

import (
	"array"
	Globals "globals";
	Object "object";
	Type "type";
	// ...
)

このコードでは、"array"の行にはセミコロンがありませんが、その後のGlobals、Object、Typeの行にはセミコロンが付いています。6gコンパイラは、"array"の行にセミコロンがなくても正しく解釈できましたが、"pretty printer"は、importブロック内の各インポートパスがセミコロンで区切られることを期待していたか、あるいは他の行との一貫性を求めていたため、"array"の行にセミコロンがないことを構文エラーと判断したと考えられます。

この修正は、"array"の行にも明示的にセミコロンを追加することで、"pretty printer"が期待する構文に合わせ、コンパイラと整形ツールの両方で一貫した解釈を可能にしました。これにより、Go言語のコードベース全体での構文の一貫性が保たれ、自動整形ツールが正しく機能するようになりました。

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

--- a/usr/gri/pretty/universe.go
+++ b/usr/gri/pretty/universe.go
@@ -5,7 +5,7 @@
 package Universe
 
 import (
-	"array"
+	"array";
 	Globals "globals";
 	Object "object";
 	Type "type";

コアとなるコードの解説

変更は、usr/gri/pretty/universe.goファイルのimportブロック内の一行です。

- "array": 変更前の行。"array"パッケージのインポート文の末尾にセミコロンがありません。
+ "array";: 変更後の行。"array"パッケージのインポート文の末尾にセミコロンが追加されています。

この修正により、importブロック内のすべてのインポートパスがセミコロンで区切られるという、"pretty printer"が期待する（または強制する）構文規則に合致するようになりました。結果として、6gコンパイラと"pretty printer"の間で生じていた構文解釈の不整合が解消され、universe.goファイルが両方のツールで正しく処理されるようになりました。

参考にした情報源リンク

GitHub上のコミットページ: https://github.com/golang/go/commit/e9741e7dbd241c53e53dfb29292030e4393a473b
Go言語の歴史に関する情報源（Web検索結果より）
- The Go Programming Language (Wikipedia)
- Go at Google: Language Design in the Service of Software Engineering (ACM Queue)
- Early Go compiler development details (various blog posts and historical articles)

comemo