問題タブ [attoparsec]

からList Int解析するためにパーサーをどのように実装できますか?Cons 0 (Cons 1 (Cons 2 (Cons 5 Nil)))list

ps : a を解析し[Int]て変換しない純粋なパーサーList Intが望ましいです。

attoparsecを使用して固定長フィールドを解析する必要がありますが、コンパイラーで苦労しています。私はまだ初心者です、以下のコードは私が持っている最も近い解決策です：

これはすべて素晴らしいですが、スペースのない都市を返すだけです。

市のテキスト文字列に20文字を使用するためにapplicativeを使用してみました

そしてさえdo syntax

しかし、どちらのアプローチもこのエラーでコンパイルに失敗します。

がタイプを持っているText -> Textときにghcが要求する原因は何ですか？takeInt -> Text -> Text

アプリケーションと構文の両方でそれを解決するにはどうすればよいですか？

スクリプト ファイルを読み込んで処理し、html ファイルに出力しようとしています。私のスクリプト ファイルでは、@title(this is a title) があるときはいつでも、html 出力にタグ[header] this is a title [/header]を追加します。したがって、私のアプローチは、最初にスクリプトファイルを読み取り、コンテンツを文字列に書き込み、文字列を処理してから、文字列を html ファイルに書き込むことです。

@title を認識するためには、文字列を 1 文字ずつ読み取る必要があります。「@」を読んだら、次の文字を検出して、それらがタイトル e かどうかを確認する必要があります。

質問: Haskell で文字列 (char のリスト) をトラバースするにはどうすればよいですか?

Haskell で pipes-attoparsec を使用してバイナリ データを解析しようとしています。パイプ (プロキシ) が関与する理由は、読み取りと解析をインターリーブして、大きなファイルで大量のメモリを使用しないようにするためです。多くのバイナリ形式はブロック (またはチャンク) に基づいており、そのサイズは多くの場合、ファイル内のフィールドによって記述されます。このようなブロックのパーサーが何と呼ばれているかはわかりませんが、タイトルの「サブパーサー」とはそういう意味です。私が抱えている問題は、潜在的に大きなメモリフットプリントなしで簡潔な方法でそれらを実装することです. それぞれが何らかの点で失敗する 2 つの代替案を思いつきました。

代替案 1 は、ブロックを別のバイト文字列に読み込み、それに対して別のパーサーを開始することです。簡潔ではありますが、ブロックが大きいとメモリ使用量が高くなります。

代替案 2 は、同じコンテキストで解析を続け、消費されたバイト数を追跡​​することです。この追跡はエラーが発生しやすく、最終的な blockParser を構成するすべてのパーサーに感染しているようです。不正な形式の入力ファイルの場合、追跡されたサイズを比較する前に、サイズ フィールドで示されるよりもさらに解析することで時間を浪費することもあります。

read-eval-print ループを持つコマンド ライン プログラムと Haskell を接続しようとしています。入力ハンドルにテキストを入力し、プロンプトが見つかるまで出力ハンドルから読み取ります (その後、繰り返します)。プロンプトが見つかるまで読み取りはブロックされますが、それ以上はブロックされません。プロンプトを作成するまで一度に 1 文字ずつ読み取る独自の小さなステート マシンをコーディングする代わりに、Parsec または Attoparsec を使用すると便利です。(問題の 1 つは、プロンプトが時間の経過とともに変化することです。そのため、一定の文字列をチェックすることはできません。)

出力ハンドルから適切な量のデータを読み取り、それをパーサーに渡す最良の方法は何ですか? ほとんどのハンドル読み取りプリミティブでは、読み取るデータの量を事前に決定する必要があるため、混乱しています。しかし、いつ停止するかを決定するのはパーサーです。

私は robots.txt ファイルを解析しており、「整形式」の robots.txt ファイルを正常に解析するパーサーを作成しました。パーサーを調整して、シンボル (コメントの # や / など) で始まる行をスキップすることができましたが、inClass "#/".

私が解決できなかった問題の 1 つは、一致させたい文字列が含まれていない行をスキップすることです。

最初に次を使用してマッチングを試みました：

satisfy (notInClass "DdUu") *> skipWhile (not . isEndOfLine)

そして、そのようにすると、ハッシュやスラッシュが文字クラスに分類されないため、特定のコメント行パーサーの必要性がなくなると考えました。問題は、これが機能しないことです。

また、「許可しない」対「許可しない」などのマッチングを解決できないため、それが機能したとしても、それが機能しないことも認識しています。

解析コードは次のとおりです (コメント スキップ コードがない場合、これは整形式の robots.txt に対してのみ機能します)。

attoparsecの使い方を学ぼうとしています。次の形式のテキスト ファイルを解析しようとしています。

私のコードはここにあります：

実行すると、次のコンパイラ エラーが発生します (ghc 7.4)

インストールの壊れたパッケージと関係があるのか​​ 、それともタイプについて何か理解していないのかはわかりません。前もって感謝します！

私は Haskell Parser Combinators についてよく読んでいて、次のような多くのトピックを見つけました。

• Parsec vs Yacc/Bison/Antlr: なぜ、いつ Parsec を使うべきか?
• 最も使いやすい Haskell 構文解析テクノロジはどれですか? またその理由は?
• Parsec または happy (alex を使用) または uu-parsinglib
• Haskell パーサーの選択
• パーサーコンビネーターを使用するのではなく、幸せのようなパーサージェネレーターを使用する利点は何ですか?

しかし、これらのトピックはParser CombinatorsすべてParser Generators.

Parser Combinator次の条件に最も適しているのはどれかお聞きしたいです。

1. エラー (エラー回復を含む) とユーザーへのメッセージを適切に管理したい
2. テキストの小さな部分をパーサーに供給できるようにしたい (一度にファイル全体ではなく)
3. 文法をうまくリデザインできるようになりたい（現在文法を開発中なので、「うまく動作すること」が重要です。）
4. 最終的なパーサーは高速である必要があります (パフォーマンスは重要ですが、ポイント 1 ～ 3 ほどではありません)。

最も人気のあるパーサーコンビネーターは次のとおりです。

• パーセク
• uu-parsinglib
• アトパーセック