問題タブ [parser-combinators]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
regex - 正規表現とパーサーコンビネーターでネステッドマークアップを制限するにはどうすればよいですか?
Scalaパーサーコンビネーターを使用する演習として、単純なWikiのようなマークアップパーサーを実装したいと思います。
これを少しずつ解決したいので、最初のバージョンで達成したいのは、単純なインラインリテラルマークアップです。
たとえば、入力文字列が次の場合:
出力文字列は次のようになります。
私はを使用してこれを解決しようとしRegexParsers
ます、そしてこれが私が今やったことです:
<code>
このコードでは、マークアップを1つだけ含む単純な入力が適切に機能します。次に例を示します。
なる
しかし、上記の例で実行すると、次のようになります。
これは、私が使用する正規表現が原因だと思います。
``
ペア で任意の文字を許可しました。
``
ネストできなかったものを制限してこの問題を修正する必要があるかどうかを知りたいですか?
scala - スカラ。難しい式パーサー。OutOfMemoryError
演算順序付きの難しい表現のパーサーを作りたいです。いくつかの例がありますが、動作が非常に遅く、例外 OutOfMemoryError がスローされます。どうすれば改善できますか?
parsing - レベル番号に基づく再帰的な解析
Scalas パーサー コンビネーターと再帰的解析に関して、(少なくとも私の見解では) トリッキーな質問があります。私は現在、次のような PL/1 構造を解析できる小さなパーサーを構築しています。
このシナリオでは、次のように AST を作成します。
親要素をその子要素に接続する必要があることを意味します。私の世界では、これは何らかの方法で再帰的なパーサーになるはずですが、私の問題は、サブレベルでの下降をいつ停止するかを制御する方法です。たとえば、「3 subdata」レコード構造を解析する場合、それ自体が低くないレベル番号 (この場合は行「3 subData2」) に到達すると停止する必要があります。
誰かがこの問題を手伝ってくれるか、良い方向に向けてくれますか? 私の現在の解決策は、接続されていない構造を解析した後にこの問題を解決することです。
前もって感謝します。
よろしくステファン
java - オプションのグループに一致するように正規表現を強制する
テキスト内の文字列「WfooXbarYbazZ」を検索したい。W、X、Y、Zは重要でない区切り文字であり、検索してはなりません。foo、bar、bazは私が興味を持っている単語です。順序はそれほど重要ではありません。必要な単語がテキストでどのように「良い」か知りたいです。
私は次のことを試みています
私の推論は次のとおりです。
- 各単語をオプションのグループにパックするので、発生する必要はありません[(?:はキャプチャされないグループであり、\ Q ...\Eはエスケープするだけです]
- 各単語を。{0,3}で区切ります(任意の文字、0〜3回出現)
この正規表現はオプションのグループのみで構成されているため常に一致しますが、すべてのオプションのグループに完全に一致する可能性がある場合でも、結果の一致は常に空になります。ただし、結果の一致を後処理したいので、可能な限りキャプチャする必要があります。
正規表現に可能な限りすべてのグループの一致を試行させることはできますか?
または、何かで区切られた複数の単語の検索を実行し、後でどの単語が発生したかをチェックして類似性を計算する方法を知っていますか?
どうもありがとうございます
scala - 元の入力を保持するためのscalaコンビネーターパーサー
別のパーサーからパーサーを作成して、消費された入力をast構文の引数として使用したいと思います。
私が持っていると言う
私が探しているのは、次の要素を構築するための別のパーサーを持つ方法です。
そのため、コンポジション内のパーサーへの元の消費された入力を取得する方法を探しています。多分次のようなものです:
この場合の署名は次のようになると思います。
私が欲しいものを手に入れる別の簡単な方法はありますか、それとも私はそのことを書く必要がありますか?おそらくもっと良い方法だと思います…</p>
parsing - (ほぼ) 自明な文法のための Scala パーサー コンビネーター
私は、次のような (非常に) 単純な言語のパーサーを作成しようとしています。
正規表現を使用して分解できます。
これは、ブロックの開始または終了に[^ ]*?\\{
一致するものが見つかるまで、基本的に文字を食べ続け ます。\\}
私の質問は、Scala のパーサー コンビネーターを使用してそれを行いたい場合、どうすればよいですか? 私は現在持っています:
しかし、これは機能しません:
block
パーサーが起動していないようで、text
パーサーが繰り返し起動されています。しかし、text
パーサーを削除すると:
私は得る:
したがって、パーサーが存在する場合を除いて、明らかにblock
パーサーはtext
機能します。何が起こっていますか?とても基本的な文法のために、これを行う「適切な」方法はありますか?
編集: タイトルを変更しました。これは、問題を解決するだけでなく、気が進まないためです。
編集:私は今これを持っています:
この背後にあるロジックは、文字ごとに、それがブロックの開始であるかどうかをテストすることです。そうでない場合は、次の文字に移動します。これは私に与えます:
これは一種の正しいです。ただし、非ブロック文字を 1 つずつ解析していますが、これはおそらくパフォーマンスの問題です (私は思いますか?)。これらの非ブロック文字をすべて一度に解析し、それらを 1 つの大きな文字列に残す方法はありますか?
parsing - Scala パーサー コンビネーター: パーサーが消費した元の文字列を取得する
だから私はこのようなパーサーの束を持っています:
}
id
基本的に、パーサーとargs
inを再利用したいのですが、とblockLine
のネストされたツリーを取得するのではなく、一致した元の文字列を取得したいと考えています。これの目的は、(後で実際の解析に使用するのと同じパーサーを使用して) スマートなテキスト前処理を行って、行の途中にテキストを挿入することです。何かのようなもの:List()
~
プリプロセッサのより高い目的は、インデントで区切られたブロックを通過して中括弧で区切られたブロックに変換することです。これにより、前処理されたファイルを後で通常のパーサーで実行できます。これを行う簡単な方法はありますか?
scala - 私が思っていたように、scalaコンビネーターパーサーはバックトラックしません...
私は自分が抱えているこの問題を盲目的に見つめてきましたが、これはおそらく本当にばかげた質問になると思います. しかし、私は自分のプライドを飲み込まなければなりません。
思ったようにバックトラックしないこのコンビネーターパーサーがあります。コンテキストを完全に削除することなく、小さな例に減らしてきました。「foobar」のように感じます-例は読みにくいだけです. ここに行きます:
したがって、3 番目のテストは失敗します。
そのため、 l が消費されたようで、litre-parser
スペースが見つからなかったときに失敗しました。しかし、その時は後戻りして、次の生産ルールを試すだろうと思っていたでしょう。前のボリューム パーサーを削除 (コメントを削除) すると成功するため、明らかにimplicitPieces
パーサーはこの行を解析します。
なぜamount
後戻りしないのですか?私は何を誤解していますか?
sql - 論理を他の中置演算子から区別する
SQL検索条件を解析しようとしていますが、パーサーが論理(AND
、OR
)を他の中置演算子と区別するのに問題があります。私はそれらを異なるノードとして解析しています(おそらくそれを行うのは難しいです)が、評価フェーズを単純化します。関連するコードスニペットは次のとおりです(必要に応じてさらに含めることができます)。
"1 = 1"
正しく解析しますComparison (Eq,Constant (Int32 1),Constant (Int32 1))
しかし、論理演算子を使用して2つの比較を結合しようとすると、たとえば、次"1 = 1 or 2 = 2"
のように解析できません。
Lnのエラー:1列:7
1=1または2=2
^
期待:入力の終わりまたは中置演算子
:7
1
エラーの前をスカラー式として解析し、or
バックトラックを押すと、中置演算子ではないこと1
を認識し、完全なスカラーとして戻り、論理演算子で結合された条件の左側を解析していることを認識しますor
。
1
代わりに、おそらく中置演算子を含む、より複雑なスカラー式が始まると仮定し続けるようです。
コードに問題がありますか、または(同じを使用して)中置演算子としてAND
/を解析するための解決策はありますか?私はそのルートに行きたくないので、どこかで単純な間違いを犯したことを望んでいます。OR
OperatorPrecedenceParser
完全なコードは要点です。
parsing - Scala で Lexical/StdLexical に position を追加する
私は、動作に関していくつかの変更を加えた StdLexical の流れでレクサーを作成しています (ただし、私の質問の目的のために、それを StdLexical に追加する方法のデモンストレーションは問題ありません)。トークンの位置を記録するためのサポートを追加しようとしていますが、問題が発生しています。単純に追加しようとするpositioned
と、完全に予期しないエラーが発生します。これは、基本的に、positioned
位置を出力しないパーサーでは実行できないことを示しています。
では、位置パーサーを使用できるようにレクサーへの入力を制限するにはどうすればよいですか、または (これが間違った質問である場合): StdLexical に位置情報を追加する最良の方法は何ですか?