主な質問から始めましょう。
なんで？
元の小さな詳細を失うことなく、大きなスクリプトパーサーをjavascriptに移植することが必要になりました。 オリジナルのパーサーがハードコアCの手ではなくyacc / bisonの観点から書かれていることは非常に幸運です。
このパーサーを移植するときが来たときに最初に思いついたのは、「javascript bison parser」をグーグル検索することでした。 もちろん、最初の結果はJisonでした。 ここに喜びがあります。 しかし、最初の実験では、Jisonは中間状態で大きな作業を行う方法を知らないことが示されました。 これらはそのようなケーブルトークンです。ヒットした場合は、コードの一部を実行して、たとえば現在のコンテキストをレクサーに伝える必要があります。 プロジェクトのGitHubでの短い連絡は、快適さをもたらしませんでした。 非常に精通した男が著者に答えた 。 私の意見では、彼はそこに多くの詳細が書かれた本を書きました！ 私は3回読み直して理解しなければなりませんでした。はい、残念ながら元のバイソンを選ばなければなりません。
バイソン
バイソンは非常にうまく設計されていると言わなければなりません。 ジェネレーター内の一部の構造をハードコードする代わりに、バイソンはテンプレート言語を使用して、必要な変数とラベルを結果のパーサーに美しく分解します。 3つの言語にはそれぞれ、スケルトンと呼ばれる独自のテンプレートがあります。 そして、すべてがうまくいきますが、そこにあるGNU m4テンプレート言語はひどいです。 この時代錯誤のため、スケルトンをJavaに静かに移植する代わりに、テンプレートジャンクでその日のジャンクを処理するだけで済みました。
lalr1.js
これは、javascript- lalr1.jsのスケルトンの名前です。 彼らはすべてララ兄弟です :)
結果は非常に個人的なものでした。 grammar.yを1つ、lalr1.jsをもう1つ、bamを使用します。
bison -S ./lalr1.js grammar.y
grammar.jsを取得します。これは、レクサーを見た後、非常に多くを解析できます。
そうそう。 このgrammar.yのすべてのCコードをjavascriptに置き換えることを忘れないことが重要です。 まあ、レクサーギャッシュ。 Cのパーサーとjavascriptのパーサーのログを比較するのは良いテストです。
エピローグ
いつものように、すべてが行われたのは、それがどれほど面白いかということだったからです。 しかし、同時に結果をベータ版にすることができました。 JavaScriptパーサーの生成に興味がある人がいる場合（コーヒースクリプト用、または直接JavaScriptをすぐに使用できる場合）、このすべてをビジネスで実行できるようになります。 github.com/bison-lalr1.jsからソースを取得し 、自分でbisonとv8 / d8をインストールすることでプレイできます。
2週間後（2013年6月28日） ：パーサーは、複雑な字句解析器と絡み合った多色域でうまく機能します。 パーサーよりも10倍遅いだけです。 すぐにリリースできるようです:)