Здравствуйте, netch80, Вы писали:

V>>Отсюда те частые наблюдения, что когда необученные программеры начинают лабать нисходящие парсеры на коленке, т.е. методом проб и ошибок, получается банальный PEG.
N>Момент, когда "отрасль нуждалась", я пропустил, видимо.

До последней четверти 90-х примерно.
У меня курсовик в 94-м был — свой парсеропостроитель из своего метаописания (на второй итерации это метаописание описание читалось уже сгенерированным кодом), потом он пошёл как часть диплома.
Тогда это был пик востребованности.

Плюс ограничения тогдашней техники на объемы памяти и быстродействия тоже требовали далеко не наколенных решений, типа PEG (вернее, более общего класса наколенных парсеров — комбинаторных).

А потом появились (скорее созрели) достаточно развитые ср-ва построения парсеров, и вкупе с Java+XML, плюс развитие интернета — всё это стало видоизменять IT, придавать всё больший уклон от фундаментальных вещей к прикладным. Сверху усилилось "память больше не ресурс" и т.д.


N>Я наблюдаю, да, невысокий, но постоянный спрос

Увы, спрос не постоянен.
Я одно время искал себя именно по этой теме, бо в "просто программеры" идти было скучновато...
Выяснилось, что каждая такая задача — "одноразовая".
Т.е., всё время держать штат подготовленных по этой области спецов любой отдельно взятой конторе бессмысленно.
И обратное тоже верно — достаточному кол-ву спецов сложно найти полную занятость именно по этой области.


N>и всё равно при этом решения на PEG занимают заметную нишу.

Вряд ли именно строгий PEG, просто PEG — это уже мем над целым направлением комбинаторных потуг.
Да, любой доведенный до практического применения комбинаторный парсер будет в существенной части своей реализации PEG, но не обязательно весь.
На то он и комбинаторный парсер. ))


N>Может быть, как раз потому, что они естественно ложатся на мышление того, кто ещё не загнан правилами LL/LR на конкретные рельсы мышления и/или не понимает важности их ограничений (а, может, это одно и то же условие).

Ну да, принцип разработки незамысловат: "водим пальчиком по разбираемому тексту и прикидываем — как бы это можно было зачитать".
При таком подходе работает "тесты вперёд", бо все конфликты могут быть обнаружены только на реальных данных, т.е. вопрос широты тестирования и банального везения тут не праздный.
Формальные грамматики, наоборот, могут судить о непротиворечивости грамматики еще на этапе её анализа (или построения по ней парсера).

В общем, это примерно как отличие статической типизации от динамической.
Второй я никогда не доверял.


A>>>>И этот тэг определяет в какой массив и какую структуру AST ты его записываешь.
N>>>Есть такие языки, но в целом это неудобно.
V>>В целом это сводит парсер по сложности примерно к хеш-таблице. ))

N>Ладно, на старый BASIC с его A! — целое, A$ — строка, A% — вещественное. Всё равно выражения надо парсить.

Но тип выражения выводить не надо, я это имел ввиду.


N>Нет, это не "первый" Fortran. Это уже правила Fortran II.

Возможно.
Я писал на таком на EC-1022. ))

Здравствуйте, netch80, Вы писали:

V>>Отсюда те частые наблюдения, что когда необученные программеры начинают лабать нисходящие парсеры на коленке, т.е. методом проб и ошибок, получается банальный PEG.
N>Момент, когда "отрасль нуждалась", я пропустил, видимо.

До последней четверти 90-х примерно.
У меня курсовик в 94-м был — свой парсеропостроитель из своего метаописания (на второй итерации это метаописание читалось уже сгенерированным кодом), потом он пошёл как часть диплома.
Тогда это был пик востребованности.

Плюс ограничения тогдашней техники на объемы памяти и быстродействия тоже требовали далеко не наколенных решений, типа PEG (вернее, более общего класса наколенных парсеров — комбинаторных).

А потом появились (скорее созрели) достаточно развитые ср-ва построения парсеров, и вкупе с Java+XML, плюс развитие интернета — всё это стало видоизменять IT, придавать всё больший уклон от фундаментальных вещей к прикладным. Сверху усилилось "память больше не ресурс" и т.д.


N>Я наблюдаю, да, невысокий, но постоянный спрос

Увы, спрос не постоянен.
Я одно время искал себя именно по этой теме, бо в "просто программеры" идти было скучновато...
Выяснилось, что каждая такая задача — "одноразовая".
Т.е., всё время держать штат подготовленных по этой области спецов любой отдельно взятой конторе бессмысленно.
И обратное тоже верно — достаточному кол-ву спецов сложно найти полную занятость именно по этой области.


N>и всё равно при этом решения на PEG занимают заметную нишу.

Вряд ли именно строгий PEG, просто PEG — это уже мем над целым направлением комбинаторных потуг.
Да, любой доведенный до практического применения комбинаторный парсер будет в существенной части своей реализации PEG, но не обязательно весь.
На то он и комбинаторный парсер. ))


N>Может быть, как раз потому, что они естественно ложатся на мышление того, кто ещё не загнан правилами LL/LR на конкретные рельсы мышления и/или не понимает важности их ограничений (а, может, это одно и то же условие).

Ну да, принцип разработки незамысловат: "водим пальчиком по разбираемому тексту и прикидываем — как бы это можно было зачитать".
При таком подходе работает "тесты вперёд", бо все конфликты могут быть обнаружены только на реальных данных, т.е. вопрос широты тестирования и банального везения тут не праздный.
Формальные грамматики, наоборот, могут судить о непротиворечивости грамматики еще на этапе её анализа (или построения по ней парсера).

В общем, это примерно как отличие статической типизации от динамической.
Второй я никогда не доверял.


A>>>>И этот тэг определяет в какой массив и какую структуру AST ты его записываешь.
N>>>Есть такие языки, но в целом это неудобно.
V>>В целом это сводит парсер по сложности примерно к хеш-таблице. ))

N>Ладно, на старый BASIC с его A! — целое, A$ — строка, A% — вещественное. Всё равно выражения надо парсить.

Но тип выражения выводить не надо, я это имел ввиду.


N>Нет, это не "первый" Fortran. Это уже правила Fortran II.

Возможно.
Я писал на таком на EC-1022. ))