符単語,standard
{std K#F85E/C4C0}
宇田川浩行stdio.h
}{交度英語のすすめ}{希哲14年1月10日11歩}{std+.h}{あれ}{希哲13年3月13日の開発}{あれ}{::std::}{std.kitetu.com}{std::}希哲館における珍奇な語彙といえば「日本語史上最大の翻訳語体系」こと希哲館訳語ばかりが注目されがちだが,実は,もう一つそれに負けず劣らず珍奇な言語関連望事がある。それが「交度英語」(Code English),略して「交語」(Codish)だ。
これは主に希哲館情報技術体系で利用しているもので,簡単に言えば,「英語を勘報機向けに簡略化した人工言語」だ。
勘報の世界では,技術者であれば誰でも理解出来るような略語というものが多数存在する。例えば,std は〈standard〉,int は〈integer〉,str は〈string〉……といった具合だ。多くは「歴史的経緯」で定着したものだ。
一方で,こうした略語の使用を避けるという文化も優勢になっている。その主な理由は,「共有しにくい」からだ。特に新しい論組言語では,英語を略さずに使う傾向があるため,妙に冗長な交度が増えた。
はっきり言おう。私は,これが非常に馬鹿げた考え方,いわば「略さない病」であると思っている。この病気によって世界から失われた効率性を金額に換算すれば天文学的なものになるに違いない。
よく考えてもみてほしい。略語というのは,どんな専門分野でも記録や情報交換の効率化のために自然発生するものだ。数学の一見意味不明な略語・記法は,数学者が本質的な仕事に専念するために編み出したものだろう。日夜神経を磨り減らして交度と向き合う情報技術者がそれを封じるのは,狂気の沙汰と言ってもいい。
実際のところ,「略語を使わない」ルールが徹底されているかというと,そうではない。例えば,String str;
なんて記述は世の中に溢れかえっている。C++ には shared_ptr(pointer),Java には println()(line)なんてものがある。「モダン」なはずの HTML5 にも img(image)やら kbd(keyboard)やら残っている。こうした混在が当たり前になっているのが現状だ。なぜなら,「略語を使わない」というのは本来不自然なこと,無理のあることだからだ。
長い方に合わせるのは無理なのだから,短い方に合わせればいい。共有しにくいなら,「略語を使わない」のではなく,「略語の辞書を作る」ことを考えればいい。頻繁に使うものなら人間は慣れる。これがつまり,交度英語の考え方だ。
交度英語では,すでに定着している英略語を基礎に,実践を通じて新しい略語を提案,問題があれば修正しながら語彙を作り上げていく。
具体的には,論組をしながら,どう略せばいいのか分からない英単語にあたった時,私はまず適当に略してみて,それをデライトで検索する。他に前例があればそれと突き合わせて修正することもあるし,無ければどういう意図で使ったかを描き出していく。これを繰り返すことで,デライトが自然と辞書の役割を果し,妥当な略語の使い方に導いてくれるようになる。
これは基本的に希哲館訳語で行っていることと同じであり,デルン/デライトがはじめて可能にしたことでもあるのだろう。
希哲館ではまだ素交の公開などはしていないので,交度英語を使った交度の実例としてすぐに見せられるものは少ないが,最近書いた「JavaScript の beforebegin,afterbegin,beforeend,afterend に代わる要素位置記法」などにはその片鱗が見えるかもしれない。
いずれ『希哲辞典』のように辞典として整えて公開することも考えているが,まずは考え方を紹介しておきたかった。
途中で終了。
tp.h を追加し tp_ を移動するついでに,xtd+.h に書いてある C_ や non_C_ などのテンプレートも tp.h に移動することにした。
改めてみると,Cμ で一番古い譜類なだけあって xtd+.h の混沌ぶりも凄い。なぜか GD 関係の交度まである。少しずつ整理を進めたい。
ついでに,これまで適当にしていたマクロの命名規則についても整理。
いつか忘れたが,Cμ 関係のマクロは _XTD_ のようにアンダースコアで囲む,という規則を採用したことがありそのままだったが,これは XTD と単純化することにした。
Cμ はあくまでも独自言語であるため C や C++ の規則に従う必要は必ずしもないが,std,xtd はもはや Cμ では自明の予約語であり,あえて特殊な記号を付ける必要もない。むしろこちらを予約してしまった方が良いだろう。
また,先日廃止するつもりで止めた std 頭譜(std+.h)について,std/string のように C++ 標準頭譜を絡包することを本格的に検討し始めた。以前から脳裏をよぎっていたことではあるが,例えばマクロで読み込み状況を確認出来るようにするなど,応用の可能性がある。これは必要に迫られた時に実装する。
昨日考案した ライブラリの分割方式を適用する前に,今後の開発の基礎になることでもあるため,Cμ の基本的なライブラリ,ヘッダー,名前空間の構成について,一日かけて熟考した。
まず,新しい着想としては,魔法引括に std.h を含むことで,非標準ライブラリの読み込み前に std.h の引括をしなくて済むことに気付いた。これは有用なので採用は確定している。
ここ最近考えるようになった xtd 表記の廃止と std 表記への統合は悩みどころだった。例えば入門者用に拡張標準のような予備知識を必要とする概念を最初から導入したくない,というのも大きかったが,説明可能性を重視すると,どうしてもライブラリ,ヘッダー,名前空間での整合性を取りたかった。このうち特に難しかったのは名前空間の問題だった。std に統合するなら,Cμ 標準 も std:: で参照出来た方が良い。この場合,基礎標準との切り分けをどうするかが難しい。
例えば何らかの名前空間を作って,use ns を使って :std:: に統合する,擬似的に std:: に見えるようにするなどの実験はいくつかしたが,名前解決が出来ない違了が出るなどしてあまり上手くいかなかった。トリッキーなことは見通しを悪くし厄介な問題を招く可能性があり避けたいこともあり,この方向は諦めた。直接 ::std:: に入れてしまうことも考えたが,基礎標準との相互運用性を考えると避けたい。さらに,基礎標準のヘッダーを引括する際,何らかの名前空間で囲って隔離するということも考えたが,これも違了で上手くいかなかった。いずれにせよ,ヘッダーの実装によっておかしくなる可能性があるので得策ではない。
結論として,:std:: はそのままにしておくことにした。
::std:: 以外の名前空間を考えると,そもそも std で統一するという方針が怪しくなってきて,kn や mus といった別の表現で統一することまで考えたが,これはこれであまり美しく感じられない。そもそもグローバル空間に展開させているので,:: でいいのではないかとも考えたが,特に C ライブラリを扱うことを考えた時に,やはり場合によって固有の名前空間は欲しい。
こうして散々考えた結果,xtd は分かりやすくて悪くないという結論に至った。基礎標準・拡張標準という Cμ の説明体系にも整合しているし,結局これが一番簡潔で分かりやすく,:xtd:: の実装も単純でよく切り分けられている。ライブラリ(libxtd.so),ヘッダー(xtd.h),名前空間で何ら問題なく整合化出来る。自分で思っていたよりよく考えられた命名だった。
結局,ドット区切りのライブラリ分割,魔法引括による std.h の自動読み込み以外はほぼ現状維持となったが,何よりの収穫は Cμ の基本方針について迷いが無くなり,確信が深まったことだった。これで気兼ねなく作業を続けることが出来る。
他に,引括や名前空間などについて熟考したことで,use ns を例えば + 記号や w/(with の意)を使って引括時に指定出来るようにする,拡張標準のヘッダーは「少なくとも一つ書けばいい」という説明の仕方にする(これまでは必ず xtd を書くことを推奨するつもりだった),という案が出来た。これらは今後検討していく。
ここに論組役が宣言や定義を追加した場合の動作は未定義とされている。ただし,テンプレートの特殊化に関しては例外がある。