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

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

進捗時限記録中略

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

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

単一文字越化

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

非特殊文字扱い

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

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

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

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

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

数式記法との整合性

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

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

越化参照

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

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

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

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

{進捗記録}{略す}{書く}{道手}{書き分けていた}{別の意味}{希哲16年1月19日の進捗時限}{希哲16年1月19日}{希哲16年1月19日の進捗}{慣れれば}...=}(46)

{希哲16年1月19日4歩 K#F85E/E74C-805D}

少し知符についての整理終了

原則として,面触れ道手フィールドなどは .先頭付け.foo()細則は各言語慣習合わせることにした。

例えば (と基礎にしている C++では,単独道手を表すのに .foo() を使うことは問題ないが,類型名一緒に表記する場合に Foo_T.foo() というのは不自然なので,従来通り Foo_T::foo() と書いた方がいいだろう。問題は,これを ::foo()略す別の意味になってしまうということだったが,単独で表記するなら原則に戻って .foo() と書いてもいいことにする。

これまで感覚書き分けていたが,少し迷うことが多かった


XMLHTML の要素に関しては,最近になって <foo> を使うようになったが,慣れれば悪くないのでこれを正式採用することにした。

要素分類名識別名に関しては,<foo.bar><foo#bar> のように書く

=}
{進捗記録}{廃止}{希哲15年12月13日の開発}{冗長過ぎる}{application/x-kn-acv}{揺らいだ}{KNIF_ 接頭子}{KFF- 接頭子}{KFF}{KN-ACV}...=}(113)

{希哲15年12月13日4歩 K#F85E/E74C-143E}

アンダースコア略記法内包子におけるアンダースコア記法廃止についての検討終了

現状譜類名(例:._acv台録名(例:/_kn/駒手名(例:_knなどにアンダースコア接頭子略記法として多用していた時期名残り多くあるが,ほとんど活用していないため,いったん廃止することを決めた

アンダースコア略記法やその応用記法問題は,明示性簡潔性ともに中途半端で,現実には使いにくいというにある。より簡潔な記法冗長な記法があると使い分け方無駄増えややこしいし,使い所無い

知機駒手では大分前から _kn よりも kn使うようになっているが,9月9日13歩以後はこの kn省けるようにしたため,_出番完全に無くなってしまった結局 _ よりも kn使ってしまう理由は,どうせ面倒臭いなら分かりやすい方が良い,ということだった気がする

これまでの経験上十分明示的な冗長記法短縮記法2つまとめていくのが一番良さそうだ。


KNIF使っていたアンダースコア記法廃止し,代わりに kn- 接頭子導入することを決めた

例えば,これまでの ._acv冗長表記.kn-acv短縮表記.acv となる。知機駒手同様,混同の恐れが無い場合は原則として短縮表記用いる

.kn.acv のようにすることも考えたが,一つの拡張子として認識されないと不都合なこともあるので,MIME 型application/x-kn-acv正式名称初期合わせるKNIF の各形式与える正式名称は,旧称 KFF の時は KFF- 接頭子KNIF になってから KN-ACV のような KN- 接頭子になり,一時 KNIF_ 接頭子揺らいだこともあったが冗長過ぎる,これを機に KN- 接頭子確定する


アンダースコア記法依存した実装排除しながら段階的置換進めていく

=}
{原則}

{}