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

Кэр>>Он покрывает большинство случаев (накладок еще не было ни разу за годы использования)
AVK>Для внутренней тулзы приемлемо, дя наружной нет.

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

Кэр>>Для задач регулярных выражений — уже есть регулярные выражения, которые обладают рядом преимуществ
AVK>И рядом недостатков. Очень серьезных недостатков.

Я что спорю? Я поэтому и говорю, что применимость их ограничена. Зато и список задач, где они нужны — он довольно стандартный. И он уже покрыт. И когда мне потребуется провалидировать email — я не буду писать regex, я найду готовый и разберу как он работает. Причем я не буду его читать — я воспользуюсь визуализатором (что нас ненавязчиво приводит опять к запросу про поддержку визуализации regex в ReSharper — я так думаю, что эта фича будет весьма востребована — как раз потому что regex юзаются время от времени, хоть и редко, а читать их тошно).

Кэр>>1. Про них знают все.
AVK>Далеко не все.

Гораздо большее количество чем те, кто знает про PEG. Было бы наоборот — это был бы точно такой же аргумент за PEG. Я по-прежнему не вижу принципиальной разницы между ними.

Кэр>>(сильно сомневаюсь, что PEG реально может это чириканье улучшить)
AVK>Очень зря ты сомневаешься.

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

Кэр>>Если только там не скрыт мега-гениальный концепт, который я тут просто еще не увидел. На одной только возможности парсить контекстно-зависимые грамматики не уедешь. Не пригождается это умение чаще чем раз в 10 лет для большинства инженеров.
AVK>Зато контекстно свободные встречаются сплошь и рядом.

На самом деле это даже не так важно — какая реальная грамматика. При реальном использовании практически любая задача парсинга становится эмпирической. Regex, который проверяет email на соответствию стандартам — он занимает что-то около 4К, насколько я помню, и нафиг такой не нужен. Все юзают короткую версию, которая простая, понятная и в общем случае неправильная. Но она работает для всех реально используемых email'ов — а что еще надо? Или HTML прекрасно разбирается стандартным .Net regex'ом, который юзает ASP.Net, несмотря на то, что сам HTML описывается контекстно-зависимой грамматикой.

Это не так в компиляторах — но там и PEG использовать как-то не с руки, если там нет разделения на токенизатор и сотоварищи. Какой-нибудь ANTLR подойдет лучше на мой взгляд.

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

NB>>>>ты регэкспы используешь? зачем?
D>>>Потому что ими задача решается проще?

NB>>какие задачи?
D>Например валидация почты.

а если у тебя для этого будет боле удобный и универсальный инструмент, ты будешь им пользоваться?

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

Кэр>Это не так в компиляторах — но там и PEG использовать как-то не с руки, если там нет разделения на токенизатор и сотоварищи. Какой-нибудь ANTLR подойдет лучше на мой взгляд.

Ващета никто не мешает в PEG разбирать не последовательность символов, а последовательность токенов от лексера. Я так делал как раз.

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


NB>а если у тебя для этого будет боле удобный и универсальный инструмент, ты будешь им пользоваться?
Тоесть от дсл мы перешли к замене регекспов, хотя они и так неплохо справляются. Вроде встречалось мне пару раз ситуация когда их не хватало, и да тут бы пригодилось что нибудь другое, но опять же выходит что фичу нужна раз в год.
Может я не тем программированием занимаюсь, как часто вы используете PEG или похожие инструменты?

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

NB>>а если у тебя для этого будет боле удобный и универсальный инструмент, ты будешь им пользоваться?
D>Тоесть от дсл мы перешли к замене регекспов, хотя они и так неплохо справляются.

тебе нужна была предметная область применения, я показал несколько

D>Вроде встречалось мне пару раз ситуация когда их не хватало, и да тут бы пригодилось что нибудь другое, но опять же выходит что фичу нужна раз в год.
D>Может я не тем программированием занимаюсь, как часто вы используете PEG или похожие инструменты?

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

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

AVK>>Для внутренней тулзы приемлемо, дя наружной нет.

Кэр>Я не знаю, что вы понимаете в данном случае под внутренней тулзой

Когда полученная программа применяется исключительно внутри.

Кэр>И когда мне потребуется провалидировать email — я не буду писать regex, я найду готовый и разберу как он работает.

А ты видел честный регекс для емейлов, который полностью удовлетворяет стандарту?

Кэр>Но одного вашего утверждаения недостаточно, чтобы я начал изучать PEG прямо сейчас — оно мне нафиг не надо для решения текущих задач.

Да и мне тебя тоже агитировать — нафик не надо. А по поводу утверждения в целом — опасны такие мысли, однако. ПОд подобным соусом легко похоронить все новое.

Кэр> А есть что поизучать для решения текущих задач. А так как спектр реальных задач хоть как-то явно не обозначен — то и приоритет в изучении этот тул получить не может.

Ну так и речь не про тебя персонально.

AVK>>Зато контекстно свободные встречаются сплошь и рядом.

Кэр>На самом деле это даже не так важно — какая реальная грамматика. При реальном использовании практически любая задача парсинга становится эмпирической.

Очень спорно. Даже в сложных случаях эмпирика обычно локализована, а в простых бывает ее нет вовсе. Причем, чем мощнее поддерживаемая движком грамматика, тем рукописного там меньше. В LL(k), к примеру, укладываются очень многие языки полностью или на 99%.

Кэр> Regex, который проверяет email на соответствию стандартам — он занимает что-то около 4К

Вот вот. Причем это 4К абсолютно нечитаемой каши.

Кэр>, насколько я помню, и нафиг такой не нужен. Все юзают короткую версию, которая простая, понятная и в общем случае неправильная. Но она работает для всех реально используемых email'ов — а что еще надо?

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

Кэр> Или HTML прекрасно разбирается стандартным .Net regex'ом, который юзает ASP.Net, несмотря на то, что сам HTML описывается контекстно-зависимой грамматикой.

А это уже сказки.

Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Я сначала подумал, что ты имеешь в виду какую-то глобальную идею, типа замены объектно-ориентированной и функциональной декомпозиции семантическими сетями. Это была бы нехилая затея, я думаю. Но, похоже, ты имеешь в виду просто какой-то парсинг на основе логических правил а ля пролог.

Вот именно. Говоря "современным" языком — тема семантических сетей не раскрыта .

Что до алгоритмов парсинга, то уверен, что специализированные алгоритмы будут эффективнее и удобнее в отладке.

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

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

AVK>Вот как раз в PEG нет выделенного токенайзера и парсера.

Не, ну парсер конечно есть по любому. Только он и в регексах есть.

Лексер отдельный тоже можно ввести, только он не обязателен.
Но таки — да, PEG во многом близок к регексам.

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

Кэр>Я Владу уже говорил — приведите список задач, где это важно. Разбирать арифметическое выражение со скобками — это лабороторная работа в универе, максимум на неделю, чтобы концепт показать.

На неделю?! Вы это серьезно написали?

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

Кэр>Теперь вы сделаете ментальное усилие и поймите о чем я говорю — в реальном мире среди тех задач, что решает ИТ инженер, это знание пригождается крайне редко. Ну просто крайне.

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

Кэр>У нас во всем продукте регекспы встречаются только в одном месте — где нужно SQL скрипты попилить по разделителю "GO". Все! Не нужны они больше никому тут. И никого вообще не волнует, реализовано ли это на убогих регулярных выражениях или мега-крутых PEG.

Какие инструменты, такие и задачи с решениями .

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

Любой разбор текста. Подчеркиваю — любой!

Кэр>Пока я слышал только мысли про DSL — но я их полезность и применимость я ставлю под большой вопрос — и это можно обсудить отдельно.

Каково мировоззрение, такие и решения.

Кэр>Потому что с текущими задачами и регулярные выражения справляются.

Дык ПЕГ будет справляться еще лучше.

Кэр>С учетом того, что применимость регулярных выражений небольшая, а известность их выше — вы собираетесь сделать частью языка PEG выражения, которые будут покрывать ту малую часть задач, которые требует сложного разбора строк и где не хватает регулярных выражений. Берем малую часть от малой части задач и получаем целевую аудиторию для фичи какого размера?

При наличии ПЕГ-парсера регулярные выражения становятся недоразумением. В отличии от них ПЕГ отлично читается и позволяет делать больше. Так что с одной стороны код станет чище, а с другой расширится сфера применения.

В Немерле ПЕГ вообще планируется встроить в макро-систему. С его помощью будет расширяться синтаксис самого языка. Ну, а DSL-естроение и язкоориентированное программирование вообще станут главными фишками Nemerle 2.

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

Кэр>Для задач регулярных выражений — уже есть регулярные выражения, которые обладают рядом преимуществ плана:
Кэр>1. Про них знают все. Их никто не помнит из головы — каждый раз инженер открывает документацию и читает, что означает это чириканье (сильно сомневаюсь, что PEG реально может это чириканье улучшить). Но их знают все. Есть даже специальные языки вроде Perl, которые молятся на них.

Кэр>2. Есть целая серия тулов для поддержки регулярных выражений. Когда у меня под рукой есть RegexBuddy — мне пофиг, как это чириканье записано. Я беру и получаю визуальную структуру регулярного выражения с картинками. Кстати, если ReSharper начнет это делать прямо в Visual Studio — будет очень круто.


Серия тулов как раз и нужна чтобы каждый раз не упираться лбом в проблемы которые создаются регексами.
Что до "Про них знают все", то это не трудно исправимо. Узнать о ПЕГ-е не долго.
А вот могут ли все писать грамматике не регексах? Количество вопросов в форумах говорит о том, что далеко не все и даже не большая часть программистов (инженэров) могут вот так запросто написать корректное регулярное выражение решеющее их задачу.
Отладка у большинства реализаций регексов попросту отсутствует.
Еще одной проблемой является, то что однажды написанное регулярное выражение крайне трудно понять (прочесть).

Так вот как раз у ПЕГ-а всех этих проблем нет. Единственное, что он несколько менее компактен, так как подразумевает использование осмысленных идентификаторов вместо птичьего языка.

Ну, и еще один плюс заключается в том, что человека знакомого с регексами довольно просто научить использованию ПЕГ-а. Большая часть конструкций регулярных выражений может использоваться и ПЕГ-грамматиках ("*", "+", "?" и т.п.). Фактически разница только в том, что ПЕГ-грамматика записывается не в одну строчку, а позволяет определять несколько именованных правил и использовать их в других правилах (в том числи и рекурсивно).

Кэр>Если только там не скрыт мега-гениальный концепт, который я тут просто еще не увидел.

Скрыта, скрыта. Но чтобы ее увидеть нужно разобраться в вопросе.

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

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

Кэр>На одной только возможности парсить контекстно-зависимые грамматики не уедешь.

Похоже ты плохо помнишь курсы из института. КЗ-грамматики как раз ПЕГ позволяет парсить очень ограничено. Зато КС он покрывает покрывает почти полностью (если исключить неоднозначные грамматики).

Вот пример грамматики ХМЛ-я

    tagOpen        = '<' s identifier attr* '>' s;
    tagClose       = '<' s '/' s identifier '>' s;
    tagEmpty       = '<' s identifier attr* '/' s '>' s;
    xtextValue     = (!('<' / '>' / '$' / ".." '$') any)+;
    xtext          = xtextValue;
    tagFull        = tagOpen content* tagClose;
    tag            = tagFull / tagEmpty;
    content        = tagFull / tagEmpty / splicedTag / xtext;
    attrValue1     = '"'  (!'"'  any)* '"' s;
    attrValue2     = '\'' (!'\'' any)* '\'' s;
    attrValue      = attrValue2 / attrValue1;
    attr           = identifier '=' s attrValue;

Думаю, что чтобы ты смог понять это описание все что тебе придется объяснить — это то что вместо используемых в регексах "|" разделяющих альтернативы в PEG-е используются "/". Сематическое отличие у них заключается в том, что "/" означает приоритетный выбор. Если первая альтернатива сопоставилась, то вторая уже даже не будет пробовать сопоставиться (первый является победителем).
Кроме того "!" — означает предикат "not". Так "!'"' any" означает, что надо распознать любой символ не являющийся кавычкой.
Ну, еще конечно надо понимать, что PEG допускает рекурсию. Казалось бы мелочь, но именно эта мелочь делает из беззубого щенка матерого волкодава. Эта мелочь позволяет разбирать практически любые компьютерные языки (да и не только компьютерные).

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

VD>В Немерле ПЕГ вообще планируется встроить в макро-систему. С его помощью будет расширяться синтаксис самого языка.

У этой фичи есть и обратная сторона — результат вашей работы можно будет использовать только из Немерле со всеми вытекающими.

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

VD>>В Немерле ПЕГ вообще планируется встроить в макро-систему. С его помощью будет расширяться синтаксис самого языка.
AVK>У этой фичи есть и обратная сторона — результат вашей работы можно будет использовать только из Немерле со всеми вытекающими.

Тут речь о том, что синтаксис для макросов можно будет описывать, используя ПЕГ-грамматику. От чего программистам на других языках ни жарко, ни холодно. Сам ПЕГ парсер сделан в виде макроса. И использовать его можно только из Немерле, да. С другой стороны, что отсюда вытекает?

Сейчас, если мне нужен парсер, я описываю грамматику во внешнем файлике — т.е. пишу своего рода ДСЛ — плюс еще шаблоны для парсера и сканера, плюс сам генератор свои сгенерированные парсеры кидает. Все это хозяйство зачастую оформляется в отдельный проект. Казалось бы какие проблемы этот отдельный проект написать на Немерле и получить интеллисенс и поддержку дебага? Ведь и так и так приходится писать ДСЛ?

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

VD>>В Немерле ПЕГ вообще планируется встроить в макро-систему. С его помощью будет расширяться синтаксис самого языка.

AVK>У этой фичи есть и обратная сторона — результат вашей работы можно будет использовать только из Немерле со всеми вытекающими.

Дык это макросистема языка. Ее никто и никогда не планировал использовать извне.

Извне можно использовать текущую реализацию PRG-парсера. Она создает обычный класс (можно даже с виртуальными методами-обработчиками). Бен немерла кончено все равно не обойтись, но использовать в проекте на других дотнет-языках все таки можно.

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

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

Кэр>Или HTML прекрасно разбирается стандартным .Net regex'ом, который юзает ASP.Net, несмотря на то, что сам HTML описывается контекстно-зависимой грамматикой.

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

Для справки:
1. HTML описывается контекстно-свободной грамматикой.
2. Регулярными выражениями принципиально невозможно разбирать HTML, так как грамматика HTML-я рекурсивна.

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

NB>не часто, потому что нормальных инструментов не много.

"не много" — это очень мягко сказано. Их практически нет. Есть только отдельный генератор парсеров для Явы.

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

AVK>PEG разбирает грамматики с мощностью примерно LL/LR(*), а не только регулярные.

Небольшое уточнение.
LL/LR — это терминалогия из области посторения ДКА по грамматикам (т.е. парсеров на их основе). ПЕГ же разбирает любые грамматики которые можно разобрать методом рекурсивного спуска с откатами. Это практически все разумно применимые грамматики за исключением неоднозначных. GLR по идее должен быть более мощным, так как позволяет парсить неоднозначные грамматики. Но на практике это никому не нужно. Парсеры на основе GLR создают множество деревьев разбора и обычно содержат шаг удаления ненужных деревев (выбора правильных деревьев).

AVK>И запись в форме PEG неизмеримо более читаема, чем птичья тропка регексов.

Я бы сказал та. Он читаем в отличии от регексов. Они (если не брать совсем простые случаи) вообще сливаются в полную кашу.

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

Кэр>На самом деле это даже не так важно — какая реальная грамматика. При реальном использовании практически любая задача парсинга становится эмпирической. Regex, который проверяет email на соответствию стандартам — он занимает что-то около 4К, насколько я помню, и нафиг такой не нужен. Все юзают короткую версию, которая простая, понятная и в общем случае неправильная. Но она работает для всех реально используемых email'ов — а что еще надо? Или HTML прекрасно разбирается стандартным .Net regex'ом, который юзает ASP.Net, несмотря на то, что сам HTML описывается контекстно-зависимой грамматикой.

Там HTML не парсится с помощью регексов. С помощью регексов выделяются серверные блоки кода и серверные элементы управления. Причем работает это реально *криво*. Попробуй закоментировать какой-нибудь контрол таким образом:

<!--asp:TextBox ID="TextBox1" Runat="server" --/>

Получишь ошибку компиляции. Нормально это? Мне кажется — нет.

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

VD>>Вот именно! А теперь задумайся о причинах. Дело ведь далеко не в том, что XML лучше дригих форматов. Иногда он бывает значительно хуже. Дело же в том, что для работа XML есть высокоуровневые средства. А для разбора других форматов нет. Отсюда можно сделать вывод, что если бы была возможность легко и просто разбирать произвольные форматы, то во многих случаях они были бы предпочтительнее.

AVK>Нельзя такой вывод сделать. Потому что выделенная предпосылка неверная.

Пока не доказано обратного будем считать ее верной.

AVK> Прелесть XML прежде всего в его предельной простоте, по крайней мере базового слоя.

Я не знаю что такое базовый слой. Но сам ХМЛ отнюдь не прост. Есть куда более простые форматы. Например, ини-файлы винды которые во всю использовались просто потому что апи для работы с ними был винде всегда (да и формат действительно очень простой), но с появлением ХМЛ-парсеров ушел в прошлое, так как ХМЛ банально мощнее (позволяет описывать древесные структуры).

AVK>По моему опыту даже то, что такое неймспейсы, понимает явно меньше половины использующих XML.

Ага. Только и он все равно сложнее тех же ини-файлов.

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

Ну, это вообще не многие могут. Думаю что если бы схемы были обязательными, то ХМЛ-ем вообще никто бы не пользовался бы.

AVK> А ведь схемы куда как проще PEG для понимания неопытному человеку.

Я бы так не сказал. Да и задачи у них все же разные.

AVK>Еще один пример — в Дельфи одно время не было собственного парсера XML, и не было нормальных средств работы с СОМ, чтобы подтянуть MSXML.

Начиная с версии 2.0 дельфи прекрасно позволяет пользоваться MSXML. Это же обычный ком-объект. Уж не знаю когда в дельфи появился TXMLDocument, но тоже давольно давно.

На коленке приличный парсер написать трудно. Это по любому задача на месяц, а возможно и не на один.