Как далее улучшить сообщения об ошибках в Scala основанные на синтаксическом-анализаторе-combinator синтаксические анализаторы?

Я кодировал синтаксический анализатор на основе синтаксического анализатора Scala combinators:

class SxmlParser extends RegexParsers with ImplicitConversions with PackratParsers {
    [...]
    lazy val document: PackratParser[AstNodeDocument] =
        ((procinst | element | comment | cdata | whitespace | text)*) ^^ {
            AstNodeDocument(_)
        }
    [...]
}
object SxmlParser {
    def parse(text: String): AstNodeDocument = {
        var ast = AstNodeDocument()
        val parser = new SxmlParser()
        val result = parser.parseAll(parser.document, new CharArrayReader(text.toArray))
        result match {
            case parser.Success(x, _) => ast = x
            case parser.NoSuccess(err, next) => {
                tool.die("failed to parse SXML input " +
                    "(line " + next.pos.line + ", column " + next.pos.column + "):\n" +
                    err + "\n" +
                    next.pos.longString)
            }
        }
        ast
    }
}

Обычно получающиеся сообщения ошибки анализа довольно хороши. Но иногда это становится справедливым

sxml: ERROR: failed to parse SXML input (line 32, column 1):
`"' expected but `' found
^

Это происходит, если символы кавычки не закрываются, и синтаксический анализатор достигает EOT. Что я хотел бы видеть, вот (1) какое производство синтаксический анализатор был в том, когда это ожидало '"' (у меня есть несколько), и (2) где во входе это производство начало анализировать (который является индикатором, где вводная кавычка находится во входе). Делает кто-либо знает, как я могу улучшить сообщения об ошибках и включать больше информации о фактическом внутреннем состоянии парсинга, когда ошибка происходит (возможно, что-то как порождающее правило stacktrace или независимо от того, что может быть дано обоснованно здесь для лучше идентификации ошибочного местоположения). BTW, вышеупомянутая "строка 32, столбец 1" является на самом деле положением EOT и следовательно бесполезный здесь, конечно.