KNEST で利用することを想定し HTML への変換に特化したデラング換配系。KNEST::HTML() から発展。
名称は Unix で標準的な字句解析系 Lex をもじり〈dexterity〉にかけたもので,希哲15年3月8日考案。
自我知番省略機能実装を終え,第二次知番改良も完了とした(20歩)。ここでやっておこうと思ったのも,途中で第零番節の削除に転換したのもあまりに急だったが,その割には終始円滑に捗り,収穫は想定をはるかに越えて多大だった。全体として大成功と言っていいだろう。
第二次知番改良を経て,知番は表記的にも内部的にも完成の域に達した。あとは仕様・実装の微調整を繰り返していく。
まず,当初の目的だった知番の簡略化は言うまでもなく大きい。これまで,一般のデライト用者は最短でも K#9-XXXX/A-YYYY
という15文字の知番で輪郭を扱う必要があった。それが第零番節の削除によって11文字の K#XXXX/YYYY
になり,自我知番の省略によって7文字の K#/YYYY
になった。知番表記仕様に関しては理想的な形だ。
「第零番節の省略」から「第零番節の削除」に転換したことで,知番周りの交度・出場整理も劇的に進んだ。これにより,効率性と保守性が大幅に向上したのはもちろん,「新括体採番法の完成」という思わぬ収穫に繋がった。未実装だった自動知番拡張もここで実装出来た。今のところ第二番節は私しか使っていない状況だが,そろそろ必要かという丁度良い時期だった。
波及効果も想定以上に大きかった。出場の見通しの悪さなどが障害になっていた機能実装に関しては大幅な所要時間短縮が見込めるようになった。特に見通しが悪い課題だった KNEST 隠しの出与え構造がこの期間に固まり,一気に実装可能性が高まった。自我知番省略機能で Dex との連携が必要になったことで,他の記法でも活かせる出与え共有機構が整った。これが無番輪符改良などにも繋がっている。
将来的に長い知番が増えた時のための「知番略記法」を中心とした第三次知番改良の方針も固まった。この長年の課題にも解決の見通しが立った。
一つ見送ったこともある。自我知番が省略された知番の写し取り時に自我知番を付け,自輪郭の描写欄などへの貼り付け時に自我知番の省略をする(4月8日の開発記録),というのは,やはり用合いとしては理想的で盛り込みたかったが,今回は見送った。このあたりの事象は Aejs で整理中なので,どうしても場当たり的な交度になってしまう。他輪郭の素出から写し取りたい時や,外部媒体に厳密な知番を貼り付けたいという時には便利だが,現時点で必要としている人は少ない。共有目的なら共有ボタンがある。交度整理しながら適当な時期に実装することにした。
無番輪符を辿った時の挙動として,まず自輪郭検索を行い,検索結果が1輪だった場合,その輪郭ページに転送することにした。これにより,よりウィキに近い使い方が出来るようになる。
最近の知番略記法についての検討で似たようなことを考えていた。Dex に必要な情報を渡す仕組みが整ったのもつい一昨日のことなので,これも第二次知番改良の副産物だ。
現状は,全輪郭検索に飛ばしているだけ。自輪郭検索にすれば自輪郭の一覧を得ることが出来るが,他自我にとっても自輪郭検索になるため,他人に見せる使い方が出来ない。Dex から自我情報を取得する手段も他自我内検索も無かったため,苦肉の策だった。
初心者にとって,輪郭間輪結のためにいちいち知番付けが必要というのは輪郭小窓以前の問題なので,出来るだけ早く実装したい。
KNEST::rep_I
}{どうやって}{必要な情報}{oln_T
}{自我知番省略機能実装}{希哲16年6月15日}{開発}{開発記録}{渡括記法}...今後の Dex 設計方針についての検討で終了。これから越化参照が大活躍しそうだ。
まず,課題だった脚注記法の実装方針について検討している内に,越化参照が部区間通信に活用出来ることに気付いた。
部区毎に越化条件の変化などがあることから,各記法の解釈は部区個体に任せたい。しかし,脚注記法のように最上位部区との出与え共有が必要な記法もある。
このような場合,単純に考えれば指示体を通して部区個体間で変数を共有するということになるが,この種の記法が増えるたびに目的別の指示体を増やすのは設計として美しくない。汎用的な変数一つに集約するのも,効率性や厳密性の観点から難がある。
ここでふと,越化参照が使えることに気付いた。下位の部区個体で中途解釈した記法には目印となる越化参照を付け,上位の部区個体で変換処理を完了させる。
これに似た部区間通信の手法は Dex 初期実装から現 &_skp;
で使い続けているが,どちらかというと「邪道」だと感じていたため,意図的に応用範囲を広げなかった。紆余曲折を経て,これが一番単純性・効率性・保守性のバランスが良いということが分かった。
これで脚注記法や目次記法の実装は容易になった。他にも,輪郭情報の参照が必要な記法など,部区間通信が必要な場面全般で越化参照が活用出来るだろう。
1月21日4歩で,&_tgt;
や &_fin;
のような目印を付加することを考えていたが,付加的な越化参照では結局正規表現の複雑化が避けられないため,実用化出来ていなかった。
昨日終えた客体表現への書き換えで Dex 初期実装の交度を整理している時,再置換を避けるため記法の一部を越化参照(当時の疑似実体参照)に置換する手法を使っていたことを思い出した。これもあまり積極的に応用範囲を広げなかった手法だが,思っていたより合理的であることに気付いた。
例えば,http
は &_http;
のように一時的に置換してしまえばいい。考えてみれば単純なことだが,灯台下暗しのごとく単純なことの真価を理解するには時間がかかるということを改めて学んだ。経験不足だと,どうしてもより高度そうなことに目移りしてしまう。
直感で編み出した Dex 初期実装の手法を再評価する十分な経験が出来たこともあるが,「越化参照」という概念が完成し,積極的な活用を考えられるようになったことも大きいのだろう。中途半端だった「疑似実体参照」から発展したのはつい先月のことだ。
`
}{解釈出来る}{完了させた}{中途半端な実装}{使用経験}{書き換えずに済む}{意図の明示}...```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``
でも,対応する逆括点さえ判別出来れば問題なく解釈出来るようになった。