私はやや複雑なデータ ファイル形式を処理するために Parsec パーサーに取り組んでいます (この形式を制御することはできません)。
私は多くの進歩を遂げましたが、現在、次のことで立ち往生しています。
次のような行を解析できる必要があります。
4 0.123 1.452 0.667 * 3.460 149 - -
意味的には、4
は nodeNum であり、Floats
と*
は負の対数確率です (したがって、*
確率ゼロの負の対数を表します)。と149
マイナス記号は本当に迷惑なので破棄しても構いませんが、少なくともパーサーを壊さないようにする必要があります。
これが私がこれまでに持っているものです:
これは、私が言及した「ジャンク」を処理します。おそらくもっと単純かもしれませんが、それ自体で機能します。
emAnnotationSet = (,,) <$> p_int <*>
(reqSpaces *> char '-') <*>
(reqSpaces *> char '-')
行のnodeNum
先頭にある は、機能する別のパーサーによって処理されるため、私が入る必要はありません。
問題はp_logProb
、emAnnotationSet
.
のパーサーはp_logProb
次のようになります。
p_logProb = liftA mkScore (lp <?> "logProb")
where lp = try dub <|> string "*"
dub = (++) <$> ((++) <$> many1 digit <*> string ".") <*> many1 digit
そして最後に、次のようにlogProb
エントリを末尾emAnnotationSet
(整数で始まる) から分離しようとします。
hmmMatchEmissions = optSpaces *> (V.fromList <$> sepBy p_logProb reqSpaces)
<* optSpaces <* emAnnotationSet <* eol
<?> "matchEmissions"
そのp_logProb
ため、数字で始まり、小数点を含み、さらに数字を持つ float でのみ成功します (この制限はファイル形式によって尊重されます)。
小数点以下を解析しない場合try
、定義内のが先頭の数字を消費しないようにすることを望んでいましたが、これは機能していないようです。p_logProb
Parsec は、その整数の数字の後に予期しないスペースがあるとまだ不平を言っていますemAnnotationSet
。
Left "hmmNode" (line 1, column 196):
unexpected " "
expecting logProb
列 196 は、マイナス記号の前の整数の後のスペースに対応しているため、p_logProb
パーサーが整数を消費していることに問題があることは明らかです。p_logProb
パーサーが先読みを正しく使用して、その入力をパーサーに残すようにするにはどうすればよいemAnnotationSet
ですか?