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

Z>Все возражения против применимости PEG можно применить и к регэкспам. Однако мало кто рискнет утверждать, что это ненужная часть фреймворка.

Утверждение, что применимость у PEG грамматик такая же, как у регулярных выражений — оно интересное, но все-таки спорное.

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

"Кэр" wrote:

> Причем чем
> больше опыта — тем меньше используют

а что используют те, у кого опыта много?

"Тролль зеленый и толстый" wrote:

> А C# — это, что ли, человеческий язык?

миллионы мух не могут ошибаться

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

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

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

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

Кэр>Утверждение, что применимость у PEG грамматик такая же, как у регулярных выражений — оно интересное, но все-таки спорное.

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

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

G>Кстати, а что насчет разбора бинарных данных?
G>Для Regexp в том виде, в котором мы сейчас видим это довольно сложная задача. Во-первых для бинарных нету "классов символов", что делает regex запись громоздкой, во вторых regexp может только вытащить токены, но не преобразовать их в структуру.

Бинарные форматы обычно примитивны и их можно разбирать куда более простыми методами. Но если они образуют сложные рекурсивные структуры, то наверно для них можно преспособить нечто вроде PEG-а.

G>Некоторые библиотеки парсер-комбинаторов умеют работать с бинарными данными не хуже чем со строками. Будет ли такая возможность в N?

Я не люблю говорить о абстрактных задачах.

В прочем на сам вопрос ответ дать можно. Комбинаторы можно с успехом использовать и из Немерле. Тот же Парсек повторили очень быстро и просто. Проблема комбинаторных парсеров в их дикой не эффективности. Если PEG можно оптимизировать, то комбинаторы раз и на всегда задают алгоритм разбора. Для разбора тех же бинарных данных эффективнее создавать специализированные ДСЛ-и и генерировать по ним эффективный код разбора.

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

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

Нельзя такой вывод сделать. Потому что выделенная предпосылка неверная. Прелесть XML прежде всего в его предельной простоте, по крайней мере базового слоя. По моему опыту даже то, что такое неймспейсы, понимает явно меньше половины использующих XML. Я уж не говорю про то, чтобы легко и непринужденно писать для него схемы. А ведь схемы куда как проще PEG для понимания неопытному человеку.
Еще один пример — в Дельфи одно время не было собственного парсера XML, и не было нормальных средств работы с СОМ, чтобы подтянуть MSXML. Что не мешало народу писать собственные его парсеры. Причем не энтузиастам побаловаться, а в самых настоящих коммерческих проектах.

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

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

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

Просто сама изначальная формулировка неправильная. Зачем спрашивать у населения, почему они не используют PEG грамматики. Причин может быть миллион. И многие из них не будут техническими.

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

LP>А он будет выглядеть точно также, как пример выше, просто вместо узкоспециализированного алгоритма разбора будет работать куда более общий прологовский механизм унификации с bactracking. Например, в прологе есть предикат Add, который позволяет практически один в один переписать твой пример:

LP>

LP>append(["foreach", space, "(", expr, space, "in", space, expr, ")", space, expr], string_to_parse)
LP>

LP>Так что дергаешь из макроса этот предикат, и все.

А в чем профит?

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

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

>> Причем чем больше опыта — тем меньше используют

S>а что используют те, у кого опыта много?

Где-то видел выражение — хорошие программисты пишут гениальные вещи тупым кодом, а не наоборот. Регулярные выражения — они слишком сложны для тупого кода

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

Кэр>Но при этом при использовании PEG грамматик надо понимать, что такое процесс токенизации, где парсинг

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

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

Кэр>>Но при этом при использовании PEG грамматик надо понимать, что такое процесс токенизации, где парсинг

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

Хм, очень интересно. А зачем тогда использовать PEG вместо регулярных выражений? Регулярные выражения хотя бы большее количество людей знает. Неужели выразительность PEG так критична?

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

Кэр>Хм, очень интересно. А зачем тогда использовать PEG вместо регулярных выражений? Регулярные выражения хотя бы большее количество людей знает. Неужели выразительность PEG так критична?
Мда. И этот человек говорит про опыт
Попробуй разобрать регулярными выражениями хотябы арифметические выражение со скобками.

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

WH>Мда. И этот человек говорит про опыт

Я говорил про опыт использования регулярных выражений. Но вы смотритесь внушительно с этим молотком и монитором, респект.

WH>Попробуй разобрать регулярными выражениями хотябы арифметические выражение со скобками.

Я Владу уже говорил — приведите список задач, где это важно. Разбирать арифметическое выражение со скобками — это лабороторная работа в универе, максимум на неделю, чтобы концепт показать. PEG я никогда не использовал — глянул в Вики, ну можно создать LL-parser, можно LR-parser, ну и ладно. Мало ли их что ли. Применяются крайне редко. Ради чего сыр-бор крайне неясно — где там критическое улучшение по сравнению с регулярными выражениями?

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

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

Кэр>PEG я никогда не использовал — глянул в Вики, ну можно создать LL-parser, можно LR-parser, ну и ладно. Мало ли их что ли. Применяются крайне редко. Ради чего сыр-бор крайне неясно — где там критическое улучшение по сравнению с регулярными выражениями?
Назад в универ учить иерархию Хомского
Так вот регулярные выражения разбирают исключительно регулярные языки.
В тоже время ПЕГ разбирает все регулярные языки. Почти все контекстно-свободные (я честно говоря не могу придумать пример КС языка который ПЕГом не разобрать). И частично контекстно-зависимые.
Арифметические выражения это контекстно-свободный язык. Те регулярными выражениями разобрать невозможно. Никак. Вообще.
Так что можешь сколько угодно размахивать своим опытом использования регулярных выражений но с их помощью ты не сделаешь даже такую простую вещь. С фундаментальными ограничениями не поспоришь.

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

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

WH>>Мда. И этот человек говорит про опыт

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

WH>>Попробуй разобрать регулярными выражениями хотябы арифметические выражение со скобками.

Кэр>Я Владу уже говорил — приведите список задач, где это важно. Разбирать арифметическое выражение со скобками — это лабороторная работа в универе, максимум на неделю, чтобы концепт показать. PEG я никогда не использовал — глянул в Вики, ну можно создать LL-parser, можно LR-parser, ну и ладно. Мало ли их что ли.
А чем тогда разбирал выражение?

Кэр>Применяются крайне редко.
Уверен?

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

WH>Назад в универ учить иерархию Хомского
WH>Так вот регулярные выражения разбирают исключительно регулярные языки.
WH>В тоже время ПЕГ разбирает все регулярные языки. Почти все контекстно-свободные (я честно говоря не могу придумать пример КС языка который ПЕГом не разобрать). И частично контекстно-зависимые.
WH>Арифметические выражения это контекстно-свободный язык. Те регулярными выражениями разобрать невозможно. Никак. Вообще.
WH>Так что можешь сколько угодно размахивать своим опытом использования регулярных выражений но с их помощью ты не сделаешь даже такую простую вещь. С фундаментальными ограничениями не поспоришь.

Учил я и теорему Хомского и прекрасно понимаю, чем отличается контекстно-свободные грамматики от контекстно-зависимых.

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

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

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

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

Есть что-то еще кроме арифметических выражений со скобочками и DSL?

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

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

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

А так регулярные выражения — это, по сути, такой же язык программирования. Он имеет все три конструкции структурного программирования:

(a)(b) — следование;
a? a|b — развилка (if, switch);
a*, a+ — повторение (for, while, do).

И чего тут сложного-то? Если человек на сишарпе пишет, то почему это для него должно быть сложно?

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

ТЗИ>Регулярные выражения могут быть сложны только тем, что их обычно записывают в одну строчку без пробелов. Любой код так будет тяжело читать.

ТЗИ>А так регулярные выражения — это, по сути, такой же язык программирования. Он имеет все три конструкции структурного программирования:

ТЗИ>(a)(b) — следование;
ТЗИ>a? a|b — развилка (if, switch);
ТЗИ>a*, a+ — повторение (for, while, do).

ТЗИ>И чего тут сложного-то? Если человек на сишарпе пишет, то почему это для него должно быть сложно?

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