val uninterestingthings = ".".r
val parser = "(?ui)(regexvalue)".r | (uninterestingthings~>parser)
Этот рекурсивный синтаксический анализатор попытается проанализировать" (? ui) (regexvalue)".r до конца входа. Находится в scala способ запретить парсинг, когда некоторое определенное количество символов было использовано "uninterestingthings"?
UPD: у Меня есть одно плохое решение:
object NonRecursiveParser extends RegexParsers with PackratParsers{
var max = -1
val maxInput2Consume = 25
def uninteresting:Regex ={
if(max<maxInput2Consume){
max+=1
("."+"{0,"+max.toString+"}").r
}else{
throw new Exception("I am tired")
}
}
lazy val value = "itt".r
def parser:Parser[Any] = (uninteresting~>value)|parser
def parseQuery(input:String) = {
try{
parse(parser, input)
}catch{
case e:Exception =>
}
}
}
Недостатки:
- не все участники являются ленивым vals, таким образом, PackratParser будет иметь штраф некоторого времени
- построение regexps на каждом "неинтересном" вызове метода - штраф времени
- использование исключения к управляющей программе - стиль кода и штраф времени
Быстрый и грязный ответ - просто ограничить количество символов в вашем регулярном выражении для неинтересных вещей и сделать его не рекурсивным:
val uninterestingthings = ".{0,60}".r // 60-chars max
val parser = (uninterestingthings~>"(?ui)(regexvalue)".r)*
На основе комментария о жадности, поедающей regexvalue, я предлагаю одно регулярное выражение:
val parser = ("(?.{0,60}?)(?ui)(regexvalue)".r)*
Но мы, кажется, отважились выйти за пределы области синтаксических анализаторов scala в мелочи регулярных выражений. Мне было бы интересно увидеть другие результаты.
Используйте токенизатор, чтобы сначала разбить вещи, используя все регулярные выражения для интересных вещей, которые вы уже знаете. Используйте одиночный "." .R
, чтобы сопоставить неинтересные вещи, если они важны для вашей грамматики. (Или выбросьте их, если они не имеют значения для грамматики.) У ваших интересных вещей теперь есть известные типы, и они идентифицируются токенизатором с использованием алгоритма, отличного от синтаксического анализа. Поскольку все проблемы упреждающего просмотра решаются токенизатором, синтаксический анализатор должен быть простым.