我一直在盲目地盯着自己的这个问题,我想这可能是一个真正愚蠢的问题。但我必须放下我的骄傲。
我有这个组合器解析器,它不会像我想象的那样回溯。我已将其简化为一个小示例,但没有完全删除上下文。感觉就像“foobar”——示例更难阅读。我来啦:
@RunWith(classOf[JUnitRunner])
class ParserBacktrackTest extends RegexParsers with Spec with ShouldMatchers {
override def skipWhitespace = false
lazy val optSpace = opt(whiteSpace)
lazy val number = """\d+([\.]\d+)?""".r
lazy val numWithOptSpace = number <~ optSpace
private def litre = numWithOptSpace <~ ("litre" | "l")
def volume = litre ^^ { case _ => "volume" }
private def namedPieces = numWithOptSpace <~ ("pcs") ^^ { case _ => "explPcs" }
private def implicitPieces = number ^^ { case _ => "implPcs" }
protected def unitAmount = namedPieces | implicitPieces
def nameOfIngredient = ".*".r
def amount = volume | unitAmount
// def amount = unitAmount
protected def ingredient = (amount <~ whiteSpace) ~ nameOfIngredient
describe("IngredientParser") {
it("should parse volume") {
shouldParse("1 litre lime")
}
it("should parse explicit pieces") {
shouldParse("1 pcs lime")
}
it("should parse implicit pieces") {
shouldParse("1 lime")
}
}
def shouldParse(row: String) = {
val result = parseAll(ingredient, row)
result match {
case Success(value, _) => println(value)
case x => println(x)
}
result.successful should be(true)
}
}
那么第三次测试失败了:
(volume~lime)
(explPcs~lime)
[1.4] failure: string matching regex `\s+' expected but `i' found
1 lime
^
所以看来litre-parser
消耗了 l 然后当它找不到任何空间时失败了。但我本以为它会回溯并尝试下一个生产规则。显然implicitPieces
解析器解析这一行,因为如果我删除前面的卷解析器(删除注释),它会成功
(implPcs~litre lime)
(explPcs~lime)
(implPcs~lime)
为什么不是amount
回溯?我有什么误解吗?
我只想发布一个最小的例子来说明我的误解。我以为这会成功:
def foo = "foo" | "fo"
def obar = "obar"
def foobar = foo ~ obar
describe("foobar-parser") {
it("should parse it") {
shouldParseWith(foobar, "foobar")
}
}
但回溯过去|
不是这样的。析取解析器将消耗“foo”并且永远不会将其返还。
它必须被标准化,以便析取被移到顶层:
def workingFooBar = ("foo" ~ obar) | ("fo" ~ obar)
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)