Как бы вы разбирали отступы (стиль Python)?

Как бы вы определили свои правила синтаксического анализатора и лексера для синтаксического анализа языка, который использует отступ для определения области видимости.

Я уже гуглил и нашел умный подход для его анализа путем генерации токенов INDENT и DEDENT в лексере.

Я пойду глубже в этой проблеме и опубликую ответ, если я приду к чему-то интересному, но я хотел бы увидеть другие подходы к проблеме.

РЕДАКТИРОВАТЬ: Как указал Чарли, уже есть другая нить, очень похожая, если не то же самое. Должен ли мой пост быть удален?

10.12.2008 16:17:25
2 ОТВЕТА

Также вы можете отследить где-нибудь в лексере, сколько идентичных элементов предшествует первой строке и передать его парсеру. Самая интересная часть - попытаться передать его парсеру правильно :) Если ваш парсер использует lookahead (здесь я имею в виду, что парсер может запросить переменное число токенов, прежде чем он действительно будет соответствовать хотя бы одному), тогда попытка передать его через одну глобальную переменную кажется это очень плохая идея (потому что лексер может проскользнуть на следующую строку и изменить значение счетчика отступов, пока анализатор все еще пытается проанализировать предыдущую строку). Кроме того, глобальные переменные являются злом во многих других случаях;) Маркировка «реального» токена первой строки в некотором смысле с помощью счетчика отступов более разумна. Я не могу привести вам точный пример (я даже не знаю, какие генераторы парсеров и лексеров вы собираетесь использовать, если таковые имеются ... ) но что-то вроде хранения данных в токенах первой строки (это может быть неудобно, если вы не можете легко получить такой токен из синтаксического анализатора) или сохранение пользовательских данных (карта, которая связывает токены с отступом, массив, где каждая строка в исходном коде в качестве индекса и значение отступа (значение элемента) кажется достаточным. Недостатком этого подхода является дополнительная сложность для синтаксического анализатора, который должен будет различать идентичные значения и изменять его поведение на его основе. Что-то вроде LOOKAHEAD ({yourConditionInJava}) для JavaCC может работать здесь, но это Недостатком этого подхода является дополнительная сложность для синтаксического анализатора, который должен будет различать идентичные значения и изменять его поведение на его основе. Что-то вроде LOOKAHEAD ({yourConditionInJava}) для JavaCC может работать здесь, но это Недостатком этого подхода является дополнительная сложность для синтаксического анализатора, который должен будет различать идентичные значения и изменять его поведение на его основе. Что-то вроде LOOKAHEAD ({yourConditionInJava}) для JavaCC может работать здесь, но этоНЕ очень хорошая идея. Многие дополнительные токены в вашем подходе кажутся менее злыми вещами :)

В качестве другой альтернативы я бы предложил смешать эти два подхода. Вы можете генерировать дополнительные токены только тогда, когда счетчик отступов меняет свое значение на следующей строке. Это как искусственный токен BEGIN и END. Таким образом, вы можете уменьшить количество «искусственных» токенов в вашем потоке, передаваемых в анализатор от лексера. Только ваша грамматика парсера должна быть скорректирована, чтобы понимать дополнительные токены ...

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

1
10.12.2008 17:27:17

Это несколько гипотетично, так как это будет зависеть от того, какую технологию вы используете для своего лексера и парсера, но проще всего было бы получить токены BEGINBLOCK и ENDBLOCK, аналогичные фигурным скобкам в C. Использование "правила офсайдов", в котором нуждается ваш лексер отслеживать стек уровней неопределенности. Когда уровень отступа увеличивается, выдает BEGINBLOCK для парсера; когда уровень отступа уменьшается, выбрасывают уровни ENDBLOCK и pop из стека.

Вот еще одно обсуждение этого на SO, кстати.

10
23.05.2017 12:00:17