（進捗時限記録中略）

今後の Dex 設計方針についての検討で終了。これから越化参照が大活躍しそうだ。

まず，課題だった脚注記法の実装方針について検討している内に，越化参照が部区間通信に活用出来ることに気付いた。

部区毎に越化条件の変化などがあることから，各記法の解釈は部区個体に任せたい。しかし，脚注記法のように最上位部区との出与え共有が必要な記法もある。

このような場合，単純に考えれば指示体を通して部区個体間で変数を共有するということになるが，この種の記法が増えるたびに目的別の指示体を増やすのは設計として美しくない。汎用的な変数一つに集約するのも，効率性や厳密性の観点から難がある。

ここでふと，越化参照が使えることに気付いた。下位の部区個体で中途解釈した記法には目印となる越化参照を付け，上位の部区個体で変換処理を完了させる。

これに似た部区間通信の手法は Dex 初期実装から現 &_skp; で使い続けているが，どちらかというと「邪道」だと感じていたため，意図的に応用範囲を広げなかった。紆余曲折を経て，これが一番単純性・効率性・保守性のバランスが良いということが分かった。

これで脚注記法や目次記法の実装は容易になった。他にも，輪郭情報の参照が必要な記法など，部区間通信が必要な場面全般で越化参照が活用出来るだろう。

もう一つ，処理済み対象の識別に関しても進展があった。

1月21日4歩で，&_tgt; や &_fin; のような目印を付加することを考えていたが，付加的な越化参照では結局正規表現の複雑化が避けられないため，実用化出来ていなかった。

昨日終えた客体表現への書き換えで Dex 初期実装の交度を整理している時，再置換を避けるため記法の一部を越化参照（当時の疑似実体参照）に置換する手法を使っていたことを思い出した。これもあまり積極的に応用範囲を広げなかった手法だが，思っていたより合理的であることに気付いた。

例えば，http は &_http; のように一時的に置換してしまえばいい。考えてみれば単純なことだが，灯台下暗しのごとく単純なことの真価を理解するには時間がかかるということを改めて学んだ。経験不足だと，どうしてもより高度そうなことに目移りしてしまう。

面白いことに，どちらも原点回帰のような発見だった。

直感で編み出した Dex 初期実装の手法を再評価する十分な経験が出来たこともあるが，「越化参照」という概念が完成し，積極的な活用を考えられるようになったことも大きいのだろう。中途半端だった「疑似実体参照」から発展したのはつい先月のことだ。

交度記法改良。

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

• 交度部区記法の開始記号・終了記号を対応する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`` でも，対応する逆括点さえ判別出来れば問題なく解釈出来るようになった。

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

（進捗時限記録中略）

色見本記法と，タグ記法にも応用出来る広義の「色記法」について少し進展があったのでまとめて終了。

色記法に関しては，背景色と前景色をどう表記し分けるかが課題だったが，色見本記法でどうせ % を使うのであれば，同時指定は [fg]%[bg] として，それぞれ [fg]%，%[bg] と書けるようにするのが良いかもしれない。

さらに，[fg]% は [fg] と略してもいいことにし，CSS との整合性を考え ; も区切り文字として使えるようにすれば，%[bg];[fg] のようにも書ける。色見本を %[bg]% で書けるとすれば，%[bg];[fg]% の短縮形ともみなせる。

この考え方なら，十分な柔軟性と明示性を持たせられそうだ。以下のような記法も概ね整合的に解釈出来る。

%black%    <!-- 小さな色見本を表示 -->
%%`black`  <!-- 指定内容の前に色見本を表示 -->
`black`%%  <!-- 指定内容の後に色見本を表示 -->

%%`black;white`%% <!-- 大きな色見本を交度付きで表示 -->

%%black;white
白文字に黒背景
%%

<{white%black}>白文字に黒背景</>
<{white;%black}>白文字に黒背景</>
<{%black;white}>白文字に黒背景</>
<{black}>黒文字</>
<{black%}>黒文字</>
<{%black}>黒背景</>

ただ，まだ確信には至っていない。もう少し煮詰める必要がある。

色見本記法がどれだけ必要とされるかは分からないが，デライト装体調整に有用なことは間違いないので出来るだけ早くまとめたい。

（進捗時限記録中略・前後）

何気なくマイクロブログサービスの用者（ユーザー）を示せる記法が欲しいという考え事をしていたら「外部サービス利用者記法」に発展したので，軽くまとめて終了。

とりあえず，分散型 SNS で使われている記法を拡張し，@[用者名]@[ドメイン名] の汎用記法を整備する方向で進めることにした。

要は，@user と書いたら Twitter に輪結したり，@user@example.com と書いたら分散型マイクロブログの捌き手に輪結してもいいのではないか，と考えたことがきっかけだった。

ここで一つ，@user@example.com は https://example.com/@user に必ず対応するのだろうかという疑問が湧いた。以前にもなんとなく考えたことはあったが，ActivityPub というか Webfinger で URL を引き出したり，面倒臭そうな気がして進展しなかった。このあたりの仕様がどうなっているのか，いまだによく分からない。

もっとも，ざっと見渡す限り分散型マイクロブログの捌き手は大体 https://example.com/@user になっているし，自分で Mastodon 捌きを運営していた時も出放りはこれだったので，事実上の標準とみなしていいのかもしれない。

Twitter は @user でいいかと思っていたが，いくら普及しているとはいえ，これは特定サービスに寄り過ぎだろうということで，@user@twitter.com で統一することを考えた。ただ，Twitter のプロフィールページの正規 URL は https://twitter.com/user だ。https://twitter.com/@user でも転送されるとはいえ，若干気持ち悪い。

さらに，この時点では @user@twitter.com と書けば @user と表示されるという仕様を考えていたため，いずれにせよ特定サービス向けの処理を追加出来るようにする必要があった。

ここまで考えたところで，いっそのこと @[用者名]@[ドメイン名] として，外部サービスの用者を指すための汎用的な記法にしてしまえばいいのではないか，と思えてきた。これは，B̅ 氏が独自に同様の記法を使っているのを見ていたことが大きかった。

[ドメイン名] は，@[用者名]@twitter のように自明なら短縮出来るようにしてもいいかもしれない。対応サービス毎に用者名を解釈，輪結先を調整し，それ以外は https://[ドメイン名]/@[用者名] に輪結する。

少し困ったのは，簡潔で分かりやすい名前が見つからないことだ。一応平たく「外部サービス利用者記法」を仮称としておく。

「異邦人記法」というのも面白いかもしれないと思ったが，一見して意味が分かりにくいので別名としてしか使えないだろう。「宛名記法」はどちらかというとメールアドレス向きか。

デライトで使う予定が全くなかったため，@[用者名] という表示は Twitter のために使うつもりだったが，これは止めておく。

そもそも SNS などでは自サービス上の用者に対する言及（メンション）という意味を持つ記法から来ている。デライトで使わなかったとしても，この種の記法を必要とするサービスにはデラングが応用出来ないことになってしまう。

ここから @[用者名] の本来の意味を考え始め，知番・輪符などと組み合わせる可能性に気付いた。これは「言及記法」として別途検討することにした。

（進捗時限記録中略）

デラング整備，越化記法と越化参照（旧・疑似実体参照）についての検討で終了。

越化（エスケープ）の基本的な仕様について記法・内部実装両面から急速にまとまった。

単一文字越化

まず，バックスラッシュを使った単一文字越化では，全ての文字を越化することにした。ただし，この「越化」は，「通常とは異なる特殊な解釈を試みること」であり，論組言語等でのそれと同様，必ずしもデラング記法としての解釈を避けることではない。

• 原則として，デラングの特殊文字であるかどうかにかかわらず，どの文字に対してもバックスラッシュを削除して当該文字を維持する。
• ただし，数式記法における \[ ... \] や \( ... \) のように，通常特殊文字として解釈されない文字に特殊な意味を与えることにも用いる。

非特殊文字の扱い

軽量標記言語で単一文字越化の対象を非特殊文字に付けた場合の挙動としては，「不明なエスケープシーケンス」などと違了を出すわけにはいかないので，以下の2つが考えられる。

• 非特殊文字に対しては何もしない（バックスラッシュも削除しない）。
• 非特殊文字も内部的には越化する（結果としてバックスラッシュは削除される）。

普段非特殊文字にあえて越化文字を付けてみることなどないので，一般的にどう実装するものなのか分からなかったが，特に定石があるわけではなさそうだ。

当初はなんとなく前者を想定していたが，この場合，全ての特殊（になりうる）文字を予め定義しておく必要があり，挙動の変則性が用者を混乱させる懸念もある。デラングの場合は文脈によって特殊文字になったりならなかったりすることも多いため，その対応も含めるとかなり複雑化してしまう。

後者の方が分かりやすいといえば分かりやすく，先日交度記法で出来た代置子方式を応用すれば実装も単純化出来る。数式記法などでは越化対象文字を判別する必要があるが，これは代置子への置換処理の前に制御子に置換すればいい。

いずれにせよ後から変更するのが難しい仕様ではないので，まずは実装の単純性を取るべきだろう。

数式記法との整合性

越化記法との整合性を深く考えず，LaTeX 方面の慣習に従い導入した数式記法の \[ ... \] や \( ... \) をどうするかという問題に少し手間取った。

これまで越化記法も「デラング記法としての解釈を避ける」ためのものとして想定していたが，ここで本来の越化という概念に立ち返り，「通常とは異なる特殊な解釈を試みる」ためのものとすることで整合させることにした。

越化参照

単一文字越化で「越化」という概念を捉え直した結果，これまで Dex で「疑似実体参照」と呼んでいたものを「越化参照」として再定義することが出来た。

これに伴い，疑似実体参照では &_foo; としていた記法を，越化の意が直感的に分かりやすい &^foo; に統一することにした。代置子は &^[連番];，「制御子」（ここで命名）は &^[名前]; となる。

越化用の代置子に関しては &^1; などと書き分けるかと考えたのとほぼ同時に前述の越化概念の拡張があり，そもそもこれまで「疑似実体参照」と呼んでいたものが越化列の役割と同じであることに気付いた。

参照先に実体があるわけではないので「疑似実体参照」という名称にはずっと違和感があったものの，良い代替案が見つからなかった。これで越化記法の課題と同時に解決してしまった。