{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{積極的な活用}{完成した}{編み出した}{面白いこと}{どちらも}{出来ていなかった}{付加的}{避けられない}...=}(143)

{希哲16年3月12日14歩 K#F85E/E74C-2A34}

進捗時限記録中略

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


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

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

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

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

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

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


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

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

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

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


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

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

{用者}{希哲16年3月12日の開発}{希哲16年3月12日の進捗}{`}{解釈出来る}{完了させた}{中途半端な実装}{使用経験}{書き換えずに済む}{意図の明示}...=}(133)

{希哲16年3月12日7歩 K#F85E/E74C-8A2F}

交度記法改良

以下の作業終えたため,ここでいったん終了

これにより,デラング記法例示洗練された

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

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

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

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

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

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


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

デラングdelangdlngdlntxt に,cuucppに,νsvsjs に,それぞれ Dex 側で変換するとりあえず大文字小文字区別しない

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

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

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


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

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


全て手定め出振るい済み

=}
{色見本}{色見本記法}{進捗記録}{希哲16年2月21日}{略す}{希哲16年2月21日の開発}{希哲16年2月21日の進捗}{まとめたい}{同時指定}{表記し分ける}...=}(52)

{希哲16年2月21日13歩 K#F85E/E74C-37C1}

進捗時限記録中略

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

色記法に関しては,背景色前景色をどう表記し分けるかが課題だったが,色見本記法でどうせ %使うのであれば,同時指定[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}>黒背景</>

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

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

=}
{用者}{デラング}{進捗記録}{希哲16年2月19日}{希哲16年2月19日の開発}{本来の意味}{自サービス}{止めておく}{独自に}{見ていた}...=}(131)

{希哲16年2月19日11歩 K#F85E/E74C-D1B5}

進捗時限記録中略前後

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

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


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

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

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


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

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

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

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


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

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


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

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

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

{用者}{デラング}{進捗記録}{数式記法}{軽量標記言語}{越化参照}{希哲16年2月4日の開発}{希哲16年2月4日21歩}{良い代替案}{深く考えず}...=}(139)

{希哲16年2月4日17歩 K#F85E/E74C-503B}

進捗時限記録中略

デラング整備越化記法越化参照疑似実体参照についての検討終了

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

単一文字越化

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

非特殊文字扱い

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

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

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

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

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

数式記法との整合性

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

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

越化参照

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

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

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

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

{解釈}

{}