旧 vio_T

Cμ における標準的な文字列型。

• 面触れ函数
• 補助函数

不具合調査，Cμ における譜類ロック関連の仕様検討など。

交度記法改良。

以下の作業を終えたため，ここでいったん終了。

• 交度部区記法の開始記号・終了記号を対応する2個以上の ` で任意化（これまでは ``` 固定）。
• 交度部区記法の言語名でデラング，Cμ，νS に対応。
• 行内交度記法内の逆括点処理の実装を完了。

これにより，デラング記法の例示も洗練された。

```txt
これまでのデラング記法の例示
```

``dlng
これからのデラング記法の例示
``

交度部区記法の開始記号・終了記号については，これまで ``` 固定だったため，交度部区記法内で交度部区記法について例示出来ないという問題があった。

行内交度記法で逆括点の数を調整出来るようにして（1月17日15歩）から，この方式で統一することを考えていた。

これを機に，逆括点の数は2個でも可とした。区切り線記法は最初から Markdown などで一般的な3個以上ではなく2個以上の - で導入したが，交度部区記法では確信が持てなかった。

交度部区記法実装からちょうど一年経ち，3個以上でなければならない理由はない，と使用経験から判断した。なんなら1個でも解釈上の問題はないはずだが，目印としての機能を考えると2個が限度だろう。他の記法との統一感もある。

これまで外部ライブラリ（highlight.js）任せだった交度部区記法の言語名を自主的に管理する第一歩として，取り急ぎデラング，Cμ，νS に対応した。

デラング，delang，dlng，dln を txt に，cμ，cu，u を cppに，νs，vs を js に，それぞれ Dex 側で変換する。とりあえず大文字小文字は区別しない。

これまではデラングを txt などと書いていたが，意図の明示という観点から問題があった。これなら今後構文ハイライトに対応した時に書き換えずに済む。

言語名の対応関係については実装に委ねるべきかとも考えたが，将来的に混乱の元になりそうな部分なので，対応関係は言語仕様で規定し，構文ハイライトなどは任意実装とすることにした。

また，用者が未定義の言語名を使用出来るように，例えば ```newlang(oldlang) のように代替言語名を指定出来る記法の検討も開始している。

1月17日15歩で，外側の逆括点の数を調整出来る仕様にしたが，`` `a` `` のように外側より少ない個数でないと上手く解釈出来ないなど中途半端な実装だったことを思い出し，実装を完了させた。

これで ` ``a`` ` でも `` `a` `` でも `` `a`` でも，対応する逆括点さえ判別出来れば問題なく解釈出来るようになった。

全て手定め・出振るい済み。

（進捗時限記録中略）

kitetu.com のサブドメイン設計についての検討で終了。

今後，デラングのように独立して参照出来るべき献典には積極的にサブドメインを与えていくことにした（例：dlng.kitetu.com）。

デラング的転回と同時にデラング文書に dlng.kitetu.com を与えることを決めたが，これを機に，知番や Cμ，SLFS 等々の公式文書にもサブドメインを与えることを考え始めた。

これまでサブドメインの追加には消極的で，例えば技術系の献典は tech.kitetu.com に集約することを考えていた。ただ，この手の URL 設計は，運営者にとっても閲覧者にとっても直感的でなく情報過多になりやすい上，階層的な整理が難しいことも多々あり，変更に弱く参照可能性の低い URL が出来がちであるという問題があった。

こういう場合の対策として，経験上「最短原則」が最善であることは分かっていて，最近は駒手にせよ各種識別子にせよ知名（最短知名原則）にせよ最短化する流れにある。サブドメインについてもこれに従うことにした。希哲館事業の要素は全て kitetu.com の階層下にある，ということだけは確かだ。もちろん，これとは別に，階層的な情報源もあった方がいいので，そこは tech.kitetu.com などに担わせる。

献典にドメインとしての独立性と統一感を同時に持たせられるのだから，むしろ，ここからがドメイン名統一の本領発揮になりそうだ。

2文字サブドメイン問題の解決

サブドメインを活用していく上で，一つ，「2文字サブドメイン問題」とでもいうべき問題があった。

例えば，Cμ にサブドメインを与えるなら cu.kitetu.com とするのが自然だが，CU はキューバの国家符号だ。

ドメイン名統一によって ccTLD を使わなくなっているため，将来的に地域別ドメインが欲しくなった時にはサブドメインを使うことになる。2文字サブドメインの使用は避けるべきかもしれない，と考えていた。キット＊メーネの mn.kitetu.com もモンゴルの MN に被っているのが少し気になってはいた。

ただ，その懸念も「もやもや」の域を出ていなかった。明らかに紛らわしいサブドメインは最初から使わないので，被るとしたら普段意識しないようなものだ。被ったとして，ドメインハックで ccTLD も有名無実化している今，そこまで神経質になることでもないだろう。そんなことのために，わざわざ不自然な表現もしたくない。とはいえ，サブドメインの選択肢が多いに越したことはない。

そこで，国家符号を表す何らかの接子の導入を考えた。Facebook のように，ja-jp と言語符号付きを基本として，言語符号がいらない場合は x-jp のように表記出来るようにするかとも考えたが，少し野暮ったい。

最終的に，4 接頭子を導入する方向で検討を進めることにした。例えば，キューバ向けのドメインは 4cu.kitetu.com として cu.kitetu.com と区別出来るようにする。衝突しなければ 4 接頭子は省略してもいいし，4ja のように言語符号に代えられてもいいだろう。4ja-jp のような表現が出来てもいい。これなら十分な簡潔性と柔軟性を兼ねられる。

例えば 4jp.kitetu.com なら www.kitetu.com と変わらない標準的な長さだし，むしろお洒落感すらあるので，これで統一して，4 接頭子無しは転送用にしてもいいくらいかもしれない。

いまのところ地域別ドメインの必要は感じておらず，将来的に必要になるかもしれない，という程度の問題なので，細かいことは追い追い決める。とりあえず理論上はすっきりしたので良かった。

（進捗時限記録中略）

希哲館訳語についての整理で終了。

〈lightweight language〉などにおける〈lightweight〉には素直に「軽量」を当てることにした。

例えば〈lightweight markup language〉は「軽標記言語」と訳していたが，見慣れない翻訳語と組み合わせると，原語がぱっと浮かんでこない。これは「軽量標記言語」の方が無難だろう。

そもそも〈lightweight〉に「軽〜」を当てるようになったのは，希哲7年頃に〈lightweight language〉への「軽言語」という翻訳語を考えてからだ。

論組言語においては，スクリプト言語の類を「軽量言語」と呼ぶのに抵抗があった。デルン開発でも鈍重な PHP から Cμ に書き換えて間もない頃だったし，ツバメ開発でも余計なパッケージが必要なことが多い論組言語は「荷物」だった。「軽量」が人間の負担の軽さを表すものだとしても，論組では実行速度の遅さが心理的な負担になることも多いわけで，違和感が拭えない。そこで少し抽象的な語感になる「軽〜」を使い始めた。

ただ，標記言語の場合は実行速度などの問題がないせいか，物量的な軽さという意味合いが強い「軽量」でもあまり違和感がない。むしろ抽象的な「軽〜」を使う方がその長所が霞んでしまう表現になる気がする。

そもそも，「軽量」という表現に問題があるとしてもそれは翻訳語の責任ではないし，そこを意訳すると〈lightweight〉という表現をめぐる議論も参照しにくくなる。

Cμ 文字列処理改良についての検討で終了。

前歩に関連して，s_T の補助函数に rpl()，rpl_fst() の削除用絡包 ers()，ers_fst() を追加することにした。Cμ で del は使いにくいし，譜類削除などで多用する rm は直感的に見分けにくいので，ers を使っておくことにした（忘れていたが，元々 std::string::erase() に対応した s_T::ers() はあった）。

ers( s, '&_fin;' ); で後始末が済むことを考えると &_tgt; よりも &_fin; を使うべきか。