レクサーと解析フェーズを1つのフェーズで混在させると、Parsecパーサーの読み込みが難しくなることがありますが、それらの処理速度も低下します。 1つの解決策は、Alexをトークナイザとして使用し、次にParsecをトークンストリームのパーサとして使用することです。レクサーを書くためのhaskell EDSLはありますか？
これは問題ありませんが、コンパイルパイプラインに1つの前処理フェーズが追加され、haskell "IDEs"などとうまく統合されないなど、私がAlexを取り除くことができればさらに良いでしょう。 Tokenizerを記述するためのhaskell EDSLのようなもので、Alexのスタイルではなく、ライブラリとしてのものです。
はい - Hackage前http://www.cse.unsw.edu.au/~chak/papers/Cha99.html
、マヌエルはCTK（コンパイラツールキット）と呼ばれるパッケージ内のコードを公開するために使用。私は最近、プロジェクトの状況が何であるか分かりません。
私は、「HaskellのLexing Haskell」というレクサーはコード生成器ではなく動的であり、リリースはHaskellにレキシングされているのに対し、ライブラリの機械はもっと一般的だと思います。 Iavor DiatchkiはコードをHackageに載せました。
パーフェクト、ありがとう！ –
レクサーとしてもParsecを使用できます。最初に文字列をパーズしてトークンに変換し、トークンを解析してターゲットデータ型に変換します。
真実ですが、やはり、表現力を失うことなくAlexのようなツールで得ることができる最小限のDFAのスピードを失ってしまいます（私は、より良いモジュール性/表現力を提供するので、Parsecを好んでいます。レクサーにとっては非常に便利です）。 しかし、少なくとも、それは2つのフェーズの混合の問題を解決します。ありがとう。 –
これは、私は後半のように探してきたが、私は実際に見てきたものは存在していない問題です。私は、タグなしトークナイザ（:: [RegEx] - > String - > [String]）を作成するRegEx EDSLを想像しています。 –
私は現在の文字列をもう一度各正規表現にマッチさせることによって任意の正規表現ライブラリを使用して簡単な解決策を考え出すことができましたが、私はすべての正規表現のセットの知識のために多くのアレックスの最適化を失います。 –