securemark 0.289.3 → 0.289.4

package/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## 0.289.4
+
+- Refactoring.
+
 ## 0.289.3
 
 - Refactoring.

package/design.md

@@ -289,9 +289,9 @@ CodeMirrorが素では速いがVimModeでは数万文字程度でも耐え難く
 
 ### バックトラック
 
-SecuremarkのAnnotation構文に典型的であるように文脈を変更する構文の中にその文脈に依存し変更される他の構文が存在する場合文脈の相違から解析結果を再利用不能(`αAβ | αA'B`)なバックトラックが生じる。またこの結果再帰的バックトラックが生じる可能性があり再帰的バックトラックは一般的にメモ化により解決されるがCommonMarkは実行性能追及のためメモ化を廃止しているためメモ化により性能を低下させてまで文脈依存構文の問題を解決するつもりはないと思われる(すなわちCommonMarkは機械を至上とし人間に制約を課す低水準の言語であり人間の需要を至上とするSecuremarkとは対極に位置する)。従って現在の再帰的バックトラックなしで解析可能な構文と最小計算量に制約されるCommonMarkにはこれ以上再帰的バックトラックが生じる可能性を増加させて文脈依存構文を追加できないという拡張性の欠陥が存在する。CommonMarkの仕様策定者が構文の拡張に(名称を維持するか否かにかかわらず)不自然なまでに消極的または進展がないのは正当な理由や怠慢からでなく文脈依存構文を追加するにつれて構文解析戦略の失敗が明白になっていくためおよび現在の高い実行性能を低下させたくないためであり陳腐な自尊心を守るためにこのような拡張性の欠陥を秘匿しCommonMarkとその仕様策定者である自分の評価が下がらないよう画策しているからである。でなければ何年も隠さず速やかにこの拡張性の欠陥を公表して助力を求めていなければならず不都合な事実を隠し全Markdown利用者および開発者を不必要に足止めした罪は重い。CommonMarkは`~~a~~`のような文脈自由構文は容易に追加できるがこうしたマージンを失えばもはや後はない。
-CommonMarkは小さく単純であるがゆえに正しくいられる象牙の塔であり仕様策定者はこの正しさを失わず正しいままでいたいがために象牙の塔に引きこもり小さな表面的完全性に固執し続けているに過ぎない。しかしCommonMarkは実際にはまったく完全ではなく本来文脈依存構文である構文を文脈自由構文として解析しているため破綻している部分があり実際のところCommonMarkは最初から現在までずっと壊れている。またCommonMarkはバックトラックなく最小計算量で解析するために文脈自由言語として設計されているが実際には文脈依存言語であるMarkdownから文脈依存構文を文脈自由構文に変換して除去することに失敗しているためCommonMarkは最初の数年間は再帰的バックトラックに気づかず最悪計算量が指数関数計算量になっており修正後は最悪計算量が当初の想定の2nから32nへと劇的に悪化している。CommonMarkが最初の数年間指数関数計算量であった事実はCommonMarkが初歩的な再帰的バックトラックの原理すら理解していない素人により設計された素人仕事である事実を証明している。一貫して素人により設計開発仕様策定されているCommonMarkは未だにバックトラックを忌避し2nの最小計算量に固執しているがそんなものはとっくの昔に破綻してるのを未練がましく執着しているだけである。最悪計算量が32nにまで悪化するのであれば計算量が少ないよう適切に設計された文脈依存言語と大差なく最初から文脈依存言語として適切に設計するほうが自然で破綻がなく拡張性を確保できていた。文脈依存構文を強引に文脈自由構文として解析して最悪計算量が当初の想定の2nから32nに劇的に悪化し結局文脈依存言語の妥当な最悪計算量の水準に落ちていることから文脈自由言語として設計されたCommonMarkの破綻と失敗は明らかでありCommonMarkは文脈自由構文に固執せず最初から多少の文脈依存構文を許容するよう設計しなければならなかった。実際には文脈依存言語であるにもかかわらず文脈自由言語としてしか構文解析できなければ構文解析が破綻し構文が増えるほど破綻が拡大することは自明でありすでに破綻済みで失敗済みのCommonMarkに未来などない。文脈依存言語であるMarkdownに対して文脈自由構文解析器として作られたCommonMarkは最初から技術選択を間違え失敗しており最初から破綻していた。CommonMarkが文脈依存言語を文脈自由言語として最小計算量で解析するために使用した手法は邪道の小手先の技術に過ぎずCommonMarkは邪道を選んだ挙句失敗に終わったのである。文脈依存言語を文脈依存言語のまま解析する正道を選んだSecuremarkが正着し文脈自由言語に歪める邪道を選んだCommonMarkが失着に終わったのは当然の帰結であり最初の言語選択の時点で決まっていたことである。文脈依存言語であるMarkdownを文脈自由言語として解析しようとして行き詰ったCommonMarkとその閉塞に技術的合理性はなくCommonMarkは最初からの失敗していた過去の遺物であり廃棄すべき負債である。CommonMarkに動きがないのはすでに破綻しており死んでいることに気付かれないように死んでいるからに過ぎない。このようにCommonMarkは完全に破綻し失敗に終わっているためCommonMarkの拡張や発展を期待しても無駄であり既存の文脈依存構文による破綻がなく新たに文脈依存構文を追加可能な拡張性の高いMarkdown仕様は新しく作り直さなければ作れない。しかしCommonMarkの仕様策定者は独自の新しい仕様においてもMarkdownをバックトラックを排除した文脈自由言語として設計しているため救いようがない。しかもその構文と仕様は機械可読性を至上としているため非常に醜く人間が書くことも読むことも困難で実用性の欠如したものである。
-Securemarkはスーパークラス構文が解析に失敗した入力をサブクラス構文で解析しないことにより再帰的バックトラックを回避する(ここで解析中の構文自身はスーパークラスとサブクラスの両方に含まれるものとする)。スーパークラス構文A(`αAβ`)の解析が失敗すればサブクラス構文B(`α'A'β'`)の解析も失敗することは自明であり解析を試みるまでもなく省略できる。これは構文の文法が生成する言語空間がスーパーセットとサブセットの関係にあるならスーパーセットの言語空間の外にある文字列はサブセットの言語空間の内に入る余地がないことからも自明である(この解析法は事前処理によっても可能だが文脈内外のオートリンクURLの括弧解析などを高速に行うことは困難であるためMarkdownをこの事前処理により高速化することは難しい)。メモ化は解析結果を再利用することで結果的に副次的効果としてバックトラックを回避しているのでありメモ化はバックトラックを回避するだけなら過剰機能であり不要である(メモ化はバックトラックがなければ使用されないためバックトラックの少ないほとんどの入力に対してはほとんど使用されず無駄であり空間計算量を常に不必要に数倍以上に増加させてまで行う利益は少ないことから構文解析において必須ではない。バックトラック回避のためにメモ化するとバックトラックなしで解析可能な場合も常に不必要に空間計算量が増加することがメモ化の最大の欠点である(この問題は解析失敗時のみメモ化すれば解消可能のはずだが基本的にはこうなる)。特に文脈自由構文解析器におけるメモ化の使用は完全に無駄でありバグである。バックトラックが他の方法で解決されるならば最終的に文脈ごと破棄され使用されないメモ化も無駄であり複数の文脈で解析結果が同一である文脈独立性のある構文ならメモ化した解析結果を異なる文脈で再利用でき有用だがそのような構文は基本的に少数であるため効果が限定的であり最悪計算量は改善されない)。この独自の解析法により、CommonMarkならば最悪時間計算量384nを要する拡張Markdown言語をSecuremarkはメモ化なしで12nの最悪時間計算量で解析しさらに一定時間内で解析不能な入力の影響を解析時間と解析範囲の制限により局限している。またSecuremarkはメモ化を行っていないため実装依存の非効率性を除けば空間計算量も小さい。時間計算量と空間計算量を合わせてO(n, n)と表記すると文脈依存言語の通常の最悪計算量はO(n^2, n)、メモ化により効率化できた場合もO(nm, nm)(S(m)>=m byte)(解析結果の構文木等を記録するため空間使用量S(m)>=m byte)に過ぎないがSecuremarkのマーキング法はO(nm, nm)(S(m)=m bit)(解析の失敗フラグしか記録しないためS(m)=m bit。また包含文字列を含め全体でn byteの構文1つに対してメモ化は少なくともn byteを消費するがマーキング法のメモリ消費量は構文全体のサイズにかかわらず1bit固定である。よって100KBの構文1つに対してメモ化は100KB以上消費するがこの場合もマーキング法は1bitしか消費しない。なお成功フラグによる解析は解析済みかの情報が追加で必要になり処理が複雑化かつほとんどの成功した解析に対してメモリ消費と追加処理が発生し解析効率が全体として悪化するが失敗フラグは少数の失敗した解析でしか解析効率が悪化しないため失敗フラグを記録するほうが全体として解析効率が高く優れている)と極めて効率的であり最も優れている。以上のようにSecuremarkの構文解析アルゴリズムの優位性は理論と実践いずれにおいても革新的かつ圧倒的である。現在のSecuremarkは開発効率と安全性優先の実装により実行性能が大きく低下しているが最悪計算量で低速に動作させる入力に対してもこの実装をサーバーで使用し多数のユーザーのリクエストに応じるには低速で脆弱性となる可能性があるがクライアントで個別のユーザーの操作に応じるには十分高速であるためクライアントで解析する限り解析の効率または速度が実用上問題となることはなく仕様が固まり実行効率優先の高速な実装に移れば速度面の懸念もないだろう。またSecuremarkの再帰数制限はパーサーコンビネーターの使用による実装依存の制限であるため再帰が生じないよう書き換えれば再帰数制限もない。SecuremarkをCommonMarkのような再帰数制限のない実装に変換することは設計上何の支障もないがCommonMarkをSecuremarkのような正常な文脈依存言語解析器に変更することは解析規則の破壊的変更なしに不可能である。具体的には二重リンク`[[]()]()`を解析するときCommonMarkはバックトラックと計算量を最小化すべく文脈自由構文解析器として設計されているためリンク構文内をリンク構文が定義されていない異なる文脈として解析せず外側のリンク構文の解析を破棄して内側のみリンク構文として解析するがSecuremarkは文脈依存構文解析器とし設計されているためリンク構文内にリンク構文が定義されておらず外側のみリンクとして解析する(ここでCommonMarkはリンク構文`[]()`の文脈自由化に角括弧`[]`に対しては成功したが丸括弧`()`に対しては失敗したことで最悪計算量が指数関数計算量ないし32nに悪化した)。多くのプログラミング言語を見ても明らかなように文脈依存言語は構文内で使用可能な構文を定義しその他の構文は構文内で使用できず例外処理するのが通常でありCommonMarkのように本来使用不能な構文を外側の構文を無効化して使用可能に変える異常な言語はほとんどの人間はCommonMark以外に見たことがないだろう。ほぼすべての人間において他のすべての言語が同じ一貫した規則を持ち同じ規則で統一的に使用できるのに対してCommonMarkだけが他と異なる異常な挙動をして認知的負荷をかけるのである。破壊的変更を避けるため旧構文で使用した苦肉の策を不必要に新構文でも使用して一貫させれば文脈依存言語なのに文脈自由言語の苦肉の策で解析される非常に不自然で理論的に設計ミスが明白で実用的にも認知的負荷の高い言語となり旧構文だけ従来通り文脈自由構文として解析し新構文を文脈依存構文として解析すればキメラ的な非常に不自然かつ歪で一貫性のない解析規則によりCommonMarkという一つの言語の中だけでもユーザーを混乱させるものとなる。そして構文エラーであることが明らかな二重リンクを意図的に入力することはほぼないためCommonMarkの異常な挙動はこれまであまり人目に付かなかったがMarkdownに文脈依存構文を追加して明らかでない構文エラーが頻発すると他の言語と逆に外側の構文を無効化していくCommonMarkの異常な挙動を頻繁に目撃し認知的負荷をかけられることになる。このようにCommonMarkは内部設計だけ文脈依存構文解析器に変更しても理論的齟齬が解析結果と使用感に明白に表れるためCommonMarkが失敗した言語である事実は到底隠し切れるものではない。Markdownはもはや負債以外の何物でもないCommonMarkの異常な解析規則を捨てて素直な文脈依存構文言語として新しい仕様を作り直すのが賢明である。
+SecuremarkのAnnotation構文に典型的であるように文脈を変更する構文の中にその文脈に依存し変更される他の構文が存在する場合文脈の相違から解析結果を再利用不能(`αAβ | αA'B`)なバックトラックが生じる。またこの結果再帰的バックトラックが生じる可能性があり再帰的バックトラックは一般的にメモ化により解決されるがCommonMarkは最小計算量と実行性能を追及するためメモ化を廃止していることからメモ化により性能を低下させてまで文脈依存構文の問題を解決するつもりはないと思われる(すなわちCommonMarkは機械を至上とし人間に制約を課す低水準の言語であり人間の需要を至上とするSecuremarkとは対極に位置する)。従って現在の再帰的バックトラックなしで解析可能な構文と最小計算量に制約されるCommonMarkにはこれ以上再帰的バックトラックが生じる可能性を増加させて文脈依存構文を追加できないという拡張性の欠陥が存在する(CommonMarkは`~~a~~`のような文脈自由構文は容易に追加できるがこうしたマージンを失えばもはや後はなく文脈依存構文を追加できないという事実に直面する)。CommonMarkの仕様策定者が構文の拡張に(名称を維持するか否かにかかわらず)不自然なまでに消極的または進展がないのは正当な理由や怠慢からでなく文脈依存構文を追加するにつれて構文解析戦略の失敗が明白になっていくためおよび最小計算量を放棄して現在の高い実行性能を低下させたくないためであり陳腐な自尊心を守るためにこのような拡張性の欠陥を秘匿しCommonMarkとその仕様策定者である自分の評価が下がらないよう画策しているからである。でなければこの拡張性の欠陥を何年も隠さず速やかに公表して助力を求めていなければならず不都合な事実を隠し陳腐な自尊心を守るために全Markdown利用者および開発者を不必要に足止めした罪は重い。
+CommonMarkは小さく単純であるがゆえに正しくいられる象牙の塔であり仕様策定者はこの正しさを失わず正しいままでいたいがために象牙の塔に引きこもり小さな表面的完全性に固執し続けているに過ぎない。しかしCommonMarkは実際にはまったく完全ではなく本来文脈依存言語であるMarkdownを文脈自由言語として解析しているため破綻している部分があり実際のところCommonMarkは最初から最後までずっと壊れている。CommonMarkはバックトラックなく最小計算量で解析するために文脈自由言語として設計されているが実際には文脈依存言語であるMarkdownから文脈依存構文を文脈自由構文に変換して除去することに失敗しているためCommonMarkは最初の数年間は再帰的バックトラックに気づかず最悪計算量が指数関数計算量になっており修正後は最悪計算量が当初の想定の2nから32nへと劇的に悪化している(より正確にはCode構文とHTML構文によりCommonMarkもSecuremarkも+2nされる)。CommonMarkが最初の数年間他人に指摘され修正されるまで指数関数計算量であった事実(https://github.com/commonmark/cmark/commit/45f4fc9b917c11221aa03e70a41e3046335a235d)はCommonMarkが初歩的な再帰的バックトラックの原理すら理解していないド素人により設計された素人仕事である事実を証明しておりたかが強調構文の解析のためにメモ化を行い(https://github.com/commonmark/commonmark.js/commit/6d7d6cf150dedb53b7f0972b79313df3364ebbed https://github.com/commonmark/commonmark.js/blob/ac8529c9f55da7fdc1186e3f34313cf411de6e71/js/stmd.js )他人にメモ化を使わない正しい実装に修正された事実(https://github.com/commonmark/commonmark.js/commit/8837f199608ac2e321f75653736747b1e692072f)もまたCommonMarkの仕様策定者がその任に堪える能力のないド素人である事実を証明している。スタックの代わりにメモ化するド素人の能力を誰が擁護できるのか？ド素人が作った結果初歩的な再帰的バックトラックすら他人に指摘されるまで気づかず最悪計算量が32nにまで著しく悪化した設計が正しいと言えるのか？不可能である。一貫してド素人により設計開発仕様策定されているCommonMarkは未だにバックトラックを忌避し2nの最小計算量に固執しているがそんなものはとっくの昔に破綻してるのを未練がましく執着しているだけである。最悪計算量が32nにまで悪化するのであれば計算量が少ないよう適切に設計された文脈依存言語と大差なく最初から文脈依存言語として適切に設計するほうが自然で破綻がなく拡張性を確保できていた。。さらにSecuremarkは再帰的バックトラックを対策しているため文脈依存構文数が増えても最悪計算量は1+mで定数的にしか増加しない(新しい構文の新しい文脈も内部の括弧類のような基本構造は共通であるため一度解析すればあとは既存の解析情報を利用してバックトラックなしで1回で解析できる)がCommonMarkは再帰的バックトラックを対策していないため文脈依存構文数が増えると最悪計算量が2^mで指数関数的に致命的に激増する。文脈依存構文を強引に文脈自由構文として解析したために最悪計算量が当初の想定の2nから32nに劇的に悪化し結局文脈依存言語の妥当な最悪計算量の水準に落ちていることおよび文脈依存構文を追加すると最悪計算量が指数関数的に悪化することから文脈自由言語として設計されたCommonMarkの破綻と失敗は明らかでありCommonMarkは文脈自由構文に固執せず最初から多少の文脈依存構文を許容するよう設計しなければならなかった。実際には文脈依存言語であるにもかかわらず文脈自由言語としてしか構文解析できなければ構文解析が破綻し構文が増えるほど破綻が拡大することは自明でありすでに破綻済みで失敗済みのCommonMarkに未来などない。文脈依存言語であるMarkdownに対して文脈自由構文解析器として作られたCommonMarkは最初から技術選択を間違え失敗しており最初から破綻していた。CommonMarkが文脈依存言語を文脈自由言語として最小計算量で解析するために使用した手法は邪道の小手先の技術に過ぎずCommonMarkは邪道を選んだ挙句失敗に終わったのである。文脈依存言語を文脈依存言語のまま解析する正道を選んだSecuremarkが正着し文脈自由言語に歪める邪道を選んだCommonMarkが失着に終わったのは当然の帰結であり最初の言語種別選択の時点で決まっていたことである。文脈依存言語であるMarkdownを文脈自由言語として解析しようとして行き詰ったCommonMarkとその閉塞に技術的合理性はなくCommonMarkは最初からの失敗していた過去の遺物であり廃棄すべき負債である。CommonMarkに動きがないのはすでに破綻しており死んでいることに気付かれないように死んでいるからに過ぎない。このようにCommonMarkは完全に破綻し失敗に終わっているためCommonMarkの拡張や発展を期待しても無駄であり既存の文脈依存構文による破綻がなく新たに文脈依存構文を追加可能な拡張性の高いMarkdown仕様は新しく作り直さなければ作れない。しかしCommonMarkの仕様策定者は独自の新しい仕様においてもMarkdownをバックトラックを排除した文脈自由言語として設計しているため救いようがない。しかもその構文と仕様は機械可読性を至上としているため非常に醜く人間が書くことも読むことも困難で実用性の欠如したものである。
+Securemarkはスーパークラス構文が解析に失敗した入力をサブクラス構文で解析しないことにより再帰的バックトラックを回避する(解析中の構文自身はスーパークラスとサブクラスの両方に含まれるものとする)。スーパークラス構文A(`αAβ`)の解析が失敗すればサブクラス構文B(`α'A'β'`)の解析も失敗することは自明であり試みるまでもなく解析を省略できる。これは二つの構文の文法が生成する各言語空間がスーパーセットとサブセットの関係にあるならスーパーセットの言語空間の外にある文字列はサブセットの言語空間の内に入る余地がないことからも自明である(この解析法は事前処理によっても可能だが文脈内外のオートリンクURLの括弧解析などを高速に行うことは困難であるためMarkdownをこの事前処理により高速化することは難しい)。メモ化は解析結果を再利用することで結果的に副次的効果としてバックトラックを回避しているのでありメモ化はバックトラックを回避するだけなら過剰機能であり不要である(メモ化はバックトラックがなければ使用されないためバックトラックの少ないほとんどの入力に対してはほとんど使用されず無駄であり空間計算量を常に不必要に数倍以上に増加させてまで行う利益は少ないことから構文解析において必須でも標準でもない。バックトラック回避のためにメモ化するとバックトラックなしで解析可能な場合も常に不必要に空間計算量が増加することがメモ化の最大の欠点である(この問題は解析失敗時のみメモ化すれば解消可能のはずだが基本的にはこうなる)。特に文脈自由構文解析器におけるメモ化の使用は完全に無駄でありバグである。バックトラックが発生しないか他の方法で解決されるならば最終的に使用されないメモ化は無駄であり複数の文脈で解析結果が同一である文脈独立性のある構文ならメモ化した解析結果を異なる文脈で再利用でき有用だがそのような構文は基本的に少数であるため効果が限定的であり最悪計算量は改善されない)。この独自の解析法により、CommonMarkならば最悪計算量384nを要する拡張Markdown言語をSecuremarkはメモ化なしで12nの最悪時間計算量で解析している。すなわち直接比較してもCommonMarkの最悪計算量32nに対してSecuremarkは12nでありSecuremarkはCommonMarkより最悪計算量が小さい。またSecuremarkはメモ化を行っていないため実装依存の非効率性を除けば空間計算量も小さい。時間計算量と空間計算量を合わせてO(n, n)と表記すると文脈依存言語の通常の最悪計算量はO(n^2, n)、メモ化により効率化できた場合もO(nm, nm)(S(m)>=m byte)(解析結果の構文木等を記録するため空間使用量S(m)>=m byte)に過ぎないがSecuremarkのマーキング法はO(nm, nm)(S(m)=m bit)(解析の失敗フラグしか記録しないためS(m)=m bit。また包含文字列を含め全体でn byteの構文1つに対してメモ化は少なくともn byteを消費するがマーキング法のメモリ消費量は構文全体のサイズにかかわらず1bit固定である。よって100KBの構文1つに対してメモ化は100KB以上消費するがこの場合もマーキング法は1bitしか消費しない。なお成功フラグによる解析は解析済みかの情報が追加で必要になり処理が複雑化かつほとんどの成功した解析に対してメモリ消費と追加処理が発生し解析効率が全体として悪化するが失敗フラグは少数の失敗した解析でしか解析効率が悪化しないため失敗フラグを記録するほうが全体として解析効率が高く優れている)と極めて効率的であり最も優れている。以上のようにSecuremarkの構文解析アルゴリズムの優位性は理論と実践いずれにおいても革新的かつ圧倒的である。現在のSecuremarkは開発効率と安全性優先の実装により実行性能が大きく低下しているが一定時間内で解析不能な入力の影響を解析時間と解析範囲の制限により局限しているため、最悪計算量で低速に動作させる入力に対してはこの実装をサーバーで使用し多数のユーザーのリクエストに応じるには低速で脆弱性となる可能性があるがクライアントで個別のユーザーの操作に応じるには十分高速であるためクライアントで解析する限り解析の効率または速度が実用上問題となることはなく仕様が固まり実行効率優先の高速な実装に移れば速度面の懸念もないだろう。またSecuremarkの再帰数制限はパーサーコンビネーターの使用による実装依存の制限であるため再帰が生じないよう書き換えれば再帰数制限もない。SecuremarkをCommonMarkのような再帰数制限のない実装に変換することは設計上何の支障もないがCommonMarkをSecuremarkのような正常な文脈依存言語解析器に変更することは解析規則の破壊的変更なしに不可能である。具体的には二重リンク`[[]()]()`を解析するときCommonMarkはバックトラックと計算量を最小化すべく文脈自由構文解析器として設計されているためリンク構文内をリンク構文が定義されていない異なる文脈として解析せず外側のリンク構文の解析を破棄して内側のみリンク構文として解析するがSecuremarkは文脈依存構文解析器とし設計されているためリンク構文内にリンク構文が定義されておらず外側のみリンクとして解析する(ここでCommonMarkはリンク構文`[]()`のバックトラック除去ひいては文脈自由化に角括弧`[]`に対しては成功したが丸括弧`()`に対しては失敗したことで最悪計算量が指数関数計算量ないし32nに悪化した。リンク構文を本来通り文脈依存構文として解析すればリンク構文の最悪計算量が2nとなり角括弧部分に限っては1nから2nに悪化するが丸括弧部分は32nから2nに著しく改善する。ここがCommonMarkの根本的な欠陥と失敗が最も明瞭に表出している部分である)。多くのプログラミング言語を見ても明らかなように文脈依存言語は構文内で使用可能な構文を定義しその他の構文は構文内で使用できず例外処理するのが通常でありCommonMarkのように本来使用不能な構文を外側の構文を無効化して使用可能に変える異常な言語はほとんどの人間はCommonMark以外に見たことがないだろう。ほぼすべての人間において他のすべての言語が同じ一貫した規則を持ち同じ規則で統一的に使用できるのに対してCommonMarkだけが他と異なる異常な挙動をして認知的負荷をかけるのである。破壊的変更を避けるため旧構文で使用した苦肉の策を不必要に新構文でも使用して一貫させれば文脈依存言語なのに文脈自由言語の苦肉の策で解析される非常に不自然で理論的に設計ミスが明白で実用的にも認知的負荷の高い言語となり旧構文だけ従来通り文脈自由構文として解析し新構文を文脈依存構文として解析すればキメラ的な非常に不自然かつ歪で一貫性のない解析規則によりCommonMarkという一つの言語の中だけでもユーザーを混乱させるものとなる。そして構文エラーであることが明らかな二重リンクを意図的に入力することはほぼないためCommonMarkの異常な挙動はこれまであまり人目に付かなかったがMarkdownに文脈依存構文を追加して明らかでない構文エラーが頻発すると他の言語と逆に外側の構文を無効化していくCommonMarkの異常な挙動を頻繁に目撃し認知的負荷をかけられることになる。このようにCommonMarkは内部設計だけ文脈依存構文解析器に変更しても理論的齟齬が解析結果と使用感に明白に表れるためCommonMarkが失敗した言語である事実は到底隠し切れるものではない。Markdownはもはや負債以外の何物でもないCommonMarkの異常な解析規則を捨てて素直な文脈依存構文言語として新しい仕様を作り直すのが賢明である。
 
 ### 最適化
 
@@ -324,7 +324,7 @@ Markdownに本当に必要な仕様はSecuremarkのクラス化制約のよう
       - altはまだしもURLは文脈依存構文としての解析を避けられないため再帰もまた避けられず公式デモページのCommonMarkで`[](`を1万回程度繰り返しただけで解析時間が1秒を超える
       - この欠陥は入れ子数を制限することで回避可能だがこれはCommonmarkは文脈依存構文全般に入れ子数制限を要することを意味する
       - CommonMarkは最初のバージョンから数年後にこの欠陥を入れ子数制限により修正しこれにより最悪計算量が当初の想定の2nから32nへと32倍に劇的に悪化したことから文脈自由言語および最小計算量としての設計と開発が破綻し失敗に終わったことが明らかである
-      - GFMも`[1]([2]()(...[34]()...))`で32回の再帰的バックトラックを行い最悪計算量が32nであることが確認できる
+      - GFMも`[0]([1]()(...[33]()...))`で32回の再帰的バックトラックを行い最悪計算量が32nであることが確認できる
       - これほど計算量が悪ければ入れ子数制限付き文脈依存言語と大差ない計算量であり素直に文脈依存言語として作り直したほうが遥かに拡張性と発展性が高く優れている
       - 計算資源は使うためにあるにもかかわらず言語と一致しない不適切な解析方法を使用してまでこの程度の計算資源を惜しんで人間に不便と不自由を強いて生産性を下げるのは本末転倒である
       - 計算機は人間の生産性に奉仕しなければならない
@@ -335,14 +335,14 @@ Markdownに本当に必要な仕様はSecuremarkのクラス化制約のよう
 
 ### CommonMarkの解析規則の問題点
 
-開閉が明示的でない構文は開閉の不明確な記号による再帰的適用を行わず早く閉じるよう解析しなければならない。このため終端記号の後ろを見て終端を中止し同じ構文を再帰的に適用してはならない。従って記号内側の非空白要件以外のflanking要件は不要である。
+開閉が明示的でない構文は開閉の不明確な記号による再帰的適用を行わず可能な限り早く閉じるよう解析しなければならない。このため終端記号の後ろを見て終端を中止し同じ構文を再帰的に適用してはならない。従って記号内側の非空白要件以外のflanking要件は不要である。
 
 ```
 flanking*!?*
 -> flanking*!?*
 ```
 
-`**`が`*`に分解されるか一貫性がなく直感的使用が困難。
+`**`が`*`に分解されるか一貫性がなく直感的使用が困難。強調を多重化する不適切で不確実な使用方法より開始記号の信頼性を損なわないことのほうが重要であるため分解しないべきである。
 
 ```
 **a*b*

package/dist/index.js

@@ -1,4 +1,4 @@
-/*! securemark v0.289.3 https://github.com/falsandtru/securemark | (c) 2017, falsandtru | UNLICENSED License */
+/*! securemark v0.289.4 https://github.com/falsandtru/securemark | (c) 2017, falsandtru | UNLICENSED License */
 (function webpackUniversalModuleDefinition(root, factory) {
 	if(typeof exports === 'object' && typeof module === 'object')
 		module.exports = factory(require("Prism"), require("DOMPurify"));
@@ -3567,7 +3567,7 @@ exports.constraint = constraint;
 /***/ },
 
 /***/ 5691
-(__unused_webpack_module, exports, __webpack_require__) {
+(__unused_webpack_module, exports) {
 
 "use strict";
 
@@ -3576,19 +3576,25 @@ Object.defineProperty(exports, "__esModule", ({
   value: true
 }));
 exports.Delimiters = void 0;
-const memoize_1 = __webpack_require__(6925);
 class Delimiters {
   constructor() {
-    this.registry = (0, memoize_1.memoize)(() => []);
+    this.heap = {};
+    this.map = new Map();
     this.delimiters = [];
     this.stack = [];
     this.states = [];
   }
+  // 手間を惜しまなければ規定のパターンはすべて配列のインデクスに変換可能。
   static signature(pattern, linebreakable) {
     switch (typeof pattern) {
       case 'undefined':
-        return `undefined`;
+        return +linebreakable;
       case 'string':
+        if (pattern.length === 1) {
+          const code = pattern.charCodeAt(0);
+          // 使用中のパターンの8ビット目が空いてるのでひとまずこうしとく
+          if ((code & 1 << 7) === 0) return code | +linebreakable << 7;
+        }
         return `s:${pattern}:${+linebreakable}`;
       case 'object':
         return `r/${pattern.source}/${+linebreakable}`;
@@ -3604,9 +3610,19 @@ class Delimiters {
         return source => pattern.test(source) || undefined;
     }
   }
+  registry(signature) {
+    if (typeof signature === 'number') {
+      return this.heap[signature] ??= [];
+    } else {
+      const ds = this.map.get(signature);
+      if (ds) return ds;
+      const blank = [];
+      this.map.set(signature, blank);
+      return blank;
+    }
+  }
   push(delims) {
     const {
-      registry,
       delimiters,
       stack
     } = this;
@@ -3619,7 +3635,7 @@ class Delimiters {
         precedence,
         linebreakable
       } = delims[i];
-      const memory = registry(signature);
+      const memory = this.registry(signature);
       const index = memory[0]?.index ?? delimiters.length;
       if (memory.length === 0) {
         const delimiter = {
@@ -5804,11 +5820,14 @@ const htmlentity_1 = __webpack_require__(470);
 const bracket_1 = __webpack_require__(4526);
 const autolink_1 = __webpack_require__(8072);
 const source_1 = __webpack_require__(8745);
-exports.inline = (0, combinator_1.lazy)(() => (0, combinator_1.union)([input => {
+exports.inline = (0, combinator_1.lazy)(() => (0, combinator_1.verify)((0, combinator_1.union)([input => {
   const {
-    source
+    source,
+    context
   } = input;
   if (source === '') return;
+  context.depth ??= 0;
+  ++context.depth;
   switch (source.slice(0, 2)) {
     case '((':
       return (0, annotation_1.annotation)(input);
@@ -5851,7 +5870,19 @@ exports.inline = (0, combinator_1.lazy)(() => (0, combinator_1.union)([input =>
     case '&':
       return (0, htmlentity_1.htmlentity)(input);
   }
-}, bracket_1.bracket, autolink_1.autolink, source_1.text]));
+}, bracket_1.bracket, autolink_1.autolink, source_1.text]), (_, rest, context) => {
+  --context.depth;
+  // ヒープを効率的に削除可能な場合は削除する。
+  // ヒープサイズは括弧類など特定の構文が完成しなかった場合にしか増加しないため
+  // ブロックごとに平均数ノード以下となることから削除せずとも平均的にはあまり影響はない。
+  //if (context.depth === 0) {
+  //  const { backtracks } = context;
+  //  while (backtracks.peek()?.key! > rest.length) {
+  //    backtracks.extract();
+  //  }
+  //}
+  return true;
+}));
 var indexee_1 = __webpack_require__(7610);
 Object.defineProperty(exports, "indexee", ({
   enumerable: true,
@@ -6247,7 +6278,8 @@ const dom_1 = __webpack_require__(394);
 const array_1 = __webpack_require__(6876);
 const substrong = (0, combinator_1.lazy)(() => (0, combinator_1.some)((0, combinator_1.union)([(0, combinator_1.some)(inline_1.inline, (0, visibility_1.blankWith)('**')), (0, combinator_1.open)((0, combinator_1.some)(inline_1.inline, '*'), (0, combinator_1.union)([exports.emstrong, strong_1.strong]))])));
 const subemphasis = (0, combinator_1.lazy)(() => (0, combinator_1.some)((0, combinator_1.union)([strong_1.strong, (0, combinator_1.some)(inline_1.inline, (0, visibility_1.blankWith)('*')), (0, combinator_1.open)((0, combinator_1.some)(inline_1.inline, '*'), (0, combinator_1.union)([exports.emstrong, strong_1.strong, emphasis_1.emphasis]))])));
-// 開閉が明示的でない構文は開閉の不明確な記号による再帰的適用を行わず早く閉じるよう解析しなければならない。
+// 開閉が明示的でない構文は開閉の不明確な記号による再帰的適用を行わず
+// 可能な限り早く閉じるよう解析しなければならない。
 // このため終端記号の後ろを見て終端を中止し同じ構文を再帰的に適用してはならない。
 exports.emstrong = (0, combinator_1.lazy)(() => (0, combinator_1.validate)('***', (0, combinator_1.precedence)(0, (0, util_1.repeat)('***', (0, combinator_1.surround)('', (0, combinator_1.recursion)(4 /* Recursion.inline */, (0, visibility_1.tightStart)((0, combinator_1.some)((0, combinator_1.union)([(0, combinator_1.some)(inline_1.inline, (0, visibility_1.blankWith)('*')), (0, combinator_1.open)((0, combinator_1.some)(inline_1.inline, '*'), inline_1.inline)])))), (0, source_1.str)(/^\*{1,3}/), false, ([, bs, cs], rest, context) => {
   switch (cs[0]) {
@@ -6520,6 +6552,11 @@ exports.indexer = void 0;
 const combinator_1 = __webpack_require__(3484);
 const index_1 = __webpack_require__(4688);
 const dom_1 = __webpack_require__(394);
+// インデクスの重複解消は不要な重複を削除するのが最もよい。
+// 複合生成インデクスは参照と同期させることが困難であり
+// 複合生成インデクスを手動で同期させるより最初から重複のない
+// テキストまたはインデクスを付けて同期が必要な機会を減らすのが
+// 継続的編集において最も簡便となる。
 exports.indexer = (0, combinator_1.surround)(/^\s+\[(?=\|\S)/, (0, combinator_1.union)([index_1.signature, (0, combinator_1.focus)(/^\|(?=\])/, () => [[(0, dom_1.html)('span', {
   class: 'indexer',
   'data-index': ''

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "securemark",
-  "version": "0.289.3",
+  "version": "0.289.4",
   "description": "Secure markdown renderer working on browsers for user input data.",
   "private": false,
   "homepage": "https://github.com/falsandtru/securemark",

package/src/combinator/data/parser/context/delimiter.ts

@@ -1,10 +1,9 @@
 import { Ctx } from '../../parser';
-import { memoize } from 'spica/memoize';
 
 interface Delimiter {
   readonly memory: Delimiter[];
   readonly index: number;
-  readonly signature: string;
+  readonly signature: number | string;
   readonly matcher: (source: string) => boolean | undefined;
   readonly precedence: number;
   readonly linebreakable: boolean;
@@ -12,11 +11,18 @@ interface Delimiter {
 }
 
 export class Delimiters {
-  public static signature(pattern: string | RegExp | undefined, linebreakable: boolean): string {
+  // 手間を惜しまなければ規定のパターンはすべて配列のインデクスに変換可能。
+  public static signature(pattern: string | RegExp | undefined, linebreakable: boolean): number | string {
     switch (typeof pattern) {
       case 'undefined':
-        return `undefined`;
+        return +linebreakable;
       case 'string':
+        assert(pattern !== '\x00');
+        if (pattern.length === 1) {
+          const code = pattern.charCodeAt(0);
+          // 使用中のパターンの8ビット目が空いてるのでひとまずこうしとく
+          if ((code & 1 << 7) === 0) return code | +linebreakable << 7;
+        }
         return `s:${pattern}:${+linebreakable}`;
       case 'object':
         return `r/${pattern.source}/${+linebreakable}`;
@@ -32,24 +38,37 @@ export class Delimiters {
         return source => pattern.test(source) || undefined;
     }
   }
-  private readonly registry = memoize<(signature: string) => Delimiter[]>(() => []);
+  private readonly heap: Record<number, Delimiter[]> = {};
+  private readonly map: Map<string, Delimiter[]> = new Map();
+  private registry(signature: number | string): Delimiter[] {
+    if (typeof signature === 'number') {
+      return this.heap[signature] ??= [];
+    }
+    else {
+      const ds = this.map.get(signature);
+      if (ds) return ds;
+      const blank: Delimiter[] = [];
+      this.map.set(signature, blank);
+      return blank;
+    }
+  }
   private readonly delimiters: Delimiter[] = [];
   private readonly stack: number[] = [];
   private readonly states: (readonly number[])[] = [];
   public push(
     delims: readonly {
-      readonly signature: string;
+      readonly signature: number | string;
       readonly matcher: (source: string) => boolean | undefined;
       readonly precedence: number;
       readonly linebreakable: boolean;
     }[]
   ): void {
-    const { registry, delimiters, stack } = this;
+    const { delimiters, stack } = this;
     // シグネチャ数以下
     assert(delimiters.length < 100);
     for (let i = 0; i < delims.length; ++i) {
       const { signature, matcher, precedence, linebreakable } = delims[i];
-      const memory = registry(signature);
+      const memory = this.registry(signature);
       const index = memory[0]?.index ?? delimiters.length;
       assert(memory.length === 0 || precedence === delimiters[index].precedence);
       if (memory.length === 0) {

package/src/combinator/data/parser.ts

@@ -19,6 +19,7 @@ export interface Ctx {
   precedence?: number;
   delimiters?: Delimiters;
   state?: number;
+  depth?: number;
   backtracks?: Record<number, number>;
   backtrack?: number;
   linebreak?: number;

package/src/parser/api/parse.test.ts

@@ -350,7 +350,7 @@ describe('Unit: parser/api/parse', () => {
 
     it('backtrack', function () {
       this.timeout(5000);
-      const str = `${'.'.repeat(7 + 0)}((${'['.repeat(13)}{{http://[[[${'.'.repeat(8328)}`;
+      const str = `${'.'.repeat(5 + 0)}{{(([[[http://${'['.repeat(13)}${'.'.repeat(8323)}`;
       assert.deepStrictEqual(
         [...parse(str).children].map(el => el.outerHTML.replace(/:\w+/, ':rnd')),
         [`<p>${str}</p>`]);
@@ -358,7 +358,7 @@ describe('Unit: parser/api/parse', () => {
 
     it('backtrack error', function () {
       this.timeout(5000);
-      const str = `${'.'.repeat(7 + 1)}((${'['.repeat(13)}{{http://[[[${'.'.repeat(8328)}`;
+      const str = `${'.'.repeat(5 + 1)}{{(([[[http://${'['.repeat(13)}${'.'.repeat(8323)}`;
       assert.deepStrictEqual(
         [...parse(str).children].map(el => el.outerHTML.replace(/:\w+/, ':rnd')),
         [

package/src/parser/inline/emstrong.ts

@@ -28,7 +28,8 @@ const subemphasis: IntermediateParser<EmphasisParser> = lazy(() => some(union([
   ])),
 ])));
 
-// 開閉が明示的でない構文は開閉の不明確な記号による再帰的適用を行わず早く閉じるよう解析しなければならない。
+// 開閉が明示的でない構文は開閉の不明確な記号による再帰的適用を行わず
+// 可能な限り早く閉じるよう解析しなければならない。
 // このため終端記号の後ろを見て終端を中止し同じ構文を再帰的に適用してはならない。
 export const emstrong: EmStrongParser = lazy(() => validate('***',
   precedence(0, repeat('***', surround(

package/src/parser/inline/extension/indexer.ts

@@ -3,6 +3,12 @@ import { union, focus, surround } from '../../../combinator';
 import { signature } from './index';
 import { html } from 'typed-dom/dom';
 
+// インデクスの重複解消は不要な重複を削除するのが最もよい。
+// 複合生成インデクスは参照と同期させることが困難であり
+// 複合生成インデクスを手動で同期させるより最初から重複のない
+// テキストまたはインデクスを付けて同期が必要な機会を減らすのが
+// 継続的編集において最も簡便となる。
+
 export const indexer: ExtensionParser.IndexerParser = surround(
   /^\s+\[(?=\|\S)/,
   union([

package/src/parser/inline/html.ts

@@ -53,8 +53,8 @@ export const html: HTMLParser = lazy(() => validate(/^<[a-z]+(?=[^\S\n]|>)/i,
       /^<([a-z]+)(?=[^\S\n]|>)/i,
       memoize(
       ([, tag]) =>
-        surround<HTMLParser.TagParser, string>(surround(
-          str(`<${tag}`), some(attribute), str(/^[^\S\n]*>/), true),
+        surround<HTMLParser.TagParser, string>(
+          surround(str(`<${tag}`), some(attribute), str(/^[^\S\n]*>/), true),
           precedence(3, recursion(Recursion.inline,
           subsequence([
             focus(/^[^\S\n]*\n/, some(inline)),

package/src/parser/inline.test.ts

@@ -70,6 +70,7 @@ describe('Unit: parser/inline', () => {
       assert.deepStrictEqual(inspect(parser('***a*b*c*')), [['**', '<em>a</em>', 'b', '<em>c</em>'], '']);
       assert.deepStrictEqual(inspect(parser('***a*b*c**')), [['**', '<em>a</em>', 'b', '<em>c</em>', '*'], '']);
       assert.deepStrictEqual(inspect(parser('***a*b*c***')), [['<strong><em>a</em>b<em>c</em></strong>'], '']);
+      assert.deepStrictEqual(inspect(parser('***a**b**c***')), [['<em><strong>a</strong>b<strong>c</strong></em>'], '']);
       assert.deepStrictEqual(inspect(parser('*(*a*)*')), [['<em><span class="paren">(<em>a</em>)</span></em>'], '']);
       assert.deepStrictEqual(inspect(parser('**(**a**)**')), [['<strong><span class="paren">(<strong>a</strong>)</span></strong>'], '']);
       assert.deepStrictEqual(inspect(parser('*[*]')), [['*', '[', '*', ']'], '']);

package/src/parser/inline.ts

@@ -1,5 +1,5 @@
 import { MarkdownParser } from '../../markdown';
-import { union, lazy } from '../combinator';
+import { union, verify, lazy } from '../combinator';
 import { annotation } from './inline/annotation';
 import { reference } from './inline/reference';
 import { template } from './inline/template';
@@ -47,10 +47,12 @@ export import ShortMediaParser = InlineParser.ShortMediaParser;
 export import BracketParser = InlineParser.BracketParser;
 export import AutolinkParser = InlineParser.AutolinkParser;
 
-export const inline: InlineParser = lazy(() => union([
+export const inline: InlineParser = lazy(() => verify(union([
   input => {
-    const { source } = input;
+    const { source, context } = input;
     if (source === '') return;
+    context.depth ??= 0;
+    ++context.depth;
     switch (source.slice(0, 2)) {
       case '((':
         return annotation(input);
@@ -104,7 +106,20 @@ export const inline: InlineParser = lazy(() => union([
   bracket,
   autolink,
   text
-])) as any;
+]), (_, rest, context) => {
+  --context.depth!;
+  assert([rest]);
+  // ヒープを効率的に削除可能な場合は削除する。
+  // ヒープサイズは括弧類など特定の構文が完成しなかった場合にしか増加しないため
+  // ブロックごとに平均数ノード以下となることから削除せずとも平均的にはあまり影響はない。
+  //if (context.depth === 0) {
+  //  const { backtracks } = context;
+  //  while (backtracks.peek()?.key! > rest.length) {
+  //    backtracks.extract();
+  //  }
+  //}
+  return true;
+})) as any;
 
 export { indexee } from './inline/extension/indexee';
 export { indexer } from './inline/extension/indexer';