プログラム言語"Whitespace"のクロス プラットフォーム対応と国際化についての考察

　檜山さんより、[日常]Whitespace言語の課題と展望にて、プログラム言語"Whitespace"のクロス プラットフォーム対応と国際化についての意見をもらいましたので、考えてみました。

　時間があまり無いので、走り書きで失礼!

　ここには複数の問題が含まれます。

プラットフォームごとに改行の定義が違うという問題 §

　まず、プラットフォームごとに改行の定義が違うという問題に関しては、解決可能と考えます。

　Whitespaceは、「Space][Tab][LF]のみを使用し、[CR]に何ら特定の意味を与えていません。つまり、XML 1.0 Recommendationがそうであるように、入力段階でも改行の正規化という規定を言語仕様に追加することによって、解決可能ではないかと思われます。

　たとえば、単独の[CR]あるいは[CR][LF]のシーケンスは、入力段階で[LF]に正規化してから処理するということです。

　問題は世の中に存在する様々な改行コードが、自分を認めろと迫ってくる可能性があることです。XMLにおいて発生した改行に関する馬鹿げた騒ぎと、それによって生まれてしまった「使われざるXML 1.1」という悲劇を考えれば、このような問題が再発しないよう配慮する価値があると思います。

　とはいえ、誰も使わないような改行コードを正規化の対象に追加することで、シンプルなWhitespaceの言語仕様が肥大化することへの懸念もあります。たとえば、メインフレームの改行コードを追加するとして、本当にメインフレーム上でWhitespaceを使うプログラマがいるのか、といった疑問は当然あり得ると思います。

意図せぬコンバージョンによる破壊 §

　これは重大な問題と言えます。

　たとえば、Windowsのコマンドプロンプトにソースを表示させると、その段階で[Tab]という概念は消失します。しかも、画面範囲を選択してクリップボードに取り込むと、行末の空白文字は全て失われます。改行も、個々の物理行の末に自動的に挿入されます。つまり、Whitespace言語のソースコードは致命的に破壊されます。

　また、電子メールによる転送の場合、テキスト本文に書き込むと、行数制限の問題から自動的に改行が挿入され、ソースコードの意図が致命的に破壊されます。

　これらの問題に対処するには、むしろWhitespace言語のソースコードはテキストではなく、特殊なバイナリーデータであると認識する必要があるかもしれません。つまり、MIMEのMedia Typesを与えるとき、text/whitespaceではなく、application/whitespaceを与える必要があると言うことです。

他の空白文字への拡大 §

　利用できる空白文字が拡大することは、より短い文字数でソースコードを記述しうる可能性をもたらすもので、その点では好感できます。

　しかし、多くのシステムが扱えない文字に対して"?"を表示する仕様を採用しています。そこから考えると、全角空白等の「全ての環境でサポートされるか不明瞭である文字」を採用することで、不可視であるという特徴が失われる可能性があります。

　従って、[Space][Tab][LF]以外の空白文字については、採用しないことが最善であると考えます。

逆に好ましい点もある §

　Whitespaceの国際化には、逆に好ましい特徴も見出せます。

　たとえば、C言語は日本のパソコンの世界に導入される際に円記号問題を引き起こしています。シフトJISで表記される文字を構成するコード群の中に、円記号と一致するコードを含む文字があるため、これを適切に扱えるように改修したコンパイラを使わないと正常にリテラル文字列を扱えない問題がありました。

　しかし、Whitespaceが使用している[Space][Tab][LF]は、いずれも制御文字と見なされるものであり、文字を表現するために使うことはどのエンコーディングも避けているコードです。([Space]だけは制御文字ではない文字であるという異論があり得ますが……)

　おそらくは、UCS-2/4, UTF-16などのISO 646 IRVと互換性の無いエンコーディングは別として、他のエンコーディングでソースコードを記述する場合に問題が起きる可能性は非常に低いものでしょう。

　このような観点から考えると、この言語は国際化に親和性が高く、既に述べたような改行コードの正規化と合わせれば、世界中のあらゆるシステム上で稼働可能な標準共通言語に発展することも、けして不可能ではないと感じます。