Правильно ищем RPAREN (чтобы включить быстрый анализ) - PullRequest
Новая
       14

Правильно ищем RPAREN (чтобы включить быстрый анализ)

2 голосов
/ 29 февраля 2012

Как лучше всего искать RPAREN в коде? Например, у меня есть этот псевдокод: 

if(a && (b || "c)"))
  |     ^---------^| CASE A
  ^----------------^ CASE B

Например, если я рассматриваю первый LPAREN, он должен совпадать с последним RPAREN (Случай B). Если я рассматриваю второй LPAREN, он должен совпадать с последним RPAREN-1 (случай A).

Обратите внимание, что есть строка "C)", имеющая RPAREN, но для случая ее следует игнорировать.

Хорошо ... Я думаю о регулярном выражении, но думаю, что оно будет очень сложным (обратите внимание, что нужны строки совпадения, регулярное выражение, а другой считает, что может включать RPAREN или что-то в этом роде). Затем я думаю об использовании ручного сканирования (с помощью кода) для обнаружения каждой части (например, регулярное выражение).

Мне нужно это для анализа кода, который я создаю (собственный язык программирования). И я хочу игнорировать чтение некоторых кодов, чтобы сделать это быстрее.

Например: 

function a() { return 1; }
function b() { return 2; }
alert(b());

В этом случае необходимо проанализировать только b(), поскольку a() никогда не используется. Поэтому я буду сканировать по стартеру { и игнорировать (но хранить) до реального }. Если функция используется, она будет проанализирована.

Мои сомнения:

  1. Regex или ручной код?
  2. Это хорошо или плохо? Игнорирование кода, если он никогда не используется, поможет улучшить скорость парсера?
  3. Не по теме: несколько советов по ускорению работы парсера? Может быть, «предварительно проанализированный» файл, в котором хранится код языка с компьютерным кодом (код операции ???)?

Ответы [ 2 ]

3 голосов
/ 29 февраля 2012

  1. Регулярное выражение не может соответствовать паренсу - это невозможно.Одним из способов разбора такого языка является lex (tokenize) и yacc (parser) - вы можете найти много информации в сети.

  2. Добавление оптимизаций в анализатор маловероятноон разбирается быстрее, но может улучшить производительность полученного кода.Хорошие и плохие - это моральные суждения, я не знаю, что они здесь значат.

  3. Сопоставление шаблонов в исходном коде и замена предварительно скомпилированного оптимизированного кода может дать вам улучшенный результат, но будет ли онускорение разбора зависит от того, как часто в коде появляются шаблоны.

2 голосов
/ 29 февраля 2012

Если вы создаете свой собственный язык, вы должны действительно узнать о стандартных методах обработки исходного кода языка. (Вы можете предлагать умные новые идеи, но большинство таких идей оказывается не такими умными, и если вы знаете стандартные, то зачастую довольно очевидно, почему).

Вы действительно не можете обработать свой код и "сопоставить" скобки с чистым регулярным выражением. Вам нужен какой-то автомат или механизм подсчета для сопоставления вложенных парантезов (или чего-либо еще, что может совпадать, например, фигурные скобки, IF и ENDIF, ...), часто называемые «синтаксический анализатор» в контексте таких задач.

Относительно ваших 3 вопросов:

1) Regex или ручной код?

Вместо этого узнайте / используйте генераторы синтаксического анализатора, например ANTLR .

2) Это хорошо или плохо? Игнорирование кода, если он никогда не используется, поможет улучшить скорость парсера?

Это действительно «преждевременная» оптимизация. Лучше просто получить быстрый двигатель разбора. ANTLR довольно хорош; Сомневаюсь, заметишь ли ты разницу. Если вы настаиваете на быстрой скорости, рассмотрите LRSTAR ; Парень, который создал это, провел последнее десятилетие микрооптимизации своих сгенерированных парсеров, и они очень быстрые

И учитывая, что вы пытаетесь реализовать язык программирования, я бы посоветовал вам беспокоиться о гораздо более серьезных проблемах его точного определения, создания работающего синтаксического анализатора и борьбы с его практическим выполнением (означает ли это интерпретация или компиляция не имеет значения). Учитывая ваш уровень понимания парсингового бизнеса, я подозреваю, что вы действительно не готовы сделать это. Вам лучше потратить некоторое время на изучение работы компиляторов в целом, поэтому у вас есть ориентир.

3) Не по теме: несколько советов по ускорению работы парсера? Может быть, «предварительно проанализированный» файл, в котором хранится код языка с компьютерным кодом (код операции ???)?

Вы можете ускорить анализатор, предварительно обработав текст и сохранив его в виде набора токенов. Вы также можете ускорить его, сохранив результат предыдущего анализа в предположении, что он не изменился (большинство исходных файлов в больших системах кода не изменяются, даже если их много перекомпилируют). Вы даже можете хранить скомпилированный код в некотором представлении вместе с исходным текстом, чтобы избежать его компиляции. [Я рассмотрел хранение скомпилированного кода для отдельных функций, подобных этой; даже когда файл редактируется, большинство функций не изменяются]. У всех этих трюков есть проблемы: как заставить программиста и редакторов сотрудничать, настроив все это? Намного проще просто создать быстрый парсер, и вам стоит начать с него и позже позаботиться о причудливых уловках.

...