PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 19:26
Оценка: 160 (22) +1 :))
Есть мнение, что новые научные теории побеждают только тогда, когда вымирают сторонники старых теорий. Удивительно, но с совершенно практическими вещами дело обстоит точно так же. Возьмем, например, такую распространенную вещь, как регулярные выражения. Они поддерживаются практически везде, библиотеки или фреймворки, поддерживающие регулярные выражения, написаны практически для всех языков программирования. При этом за последние два десятилетия регулярные выражения мало изменились. В частности, они как были, так и остались "write only" – будучи единожды написанными, они практически не поддаются прочтению. Оно и понятно, не так ведь просто догадаться, что делает набор из палочек и скобочек типа ("(\\"|\\\\|[^"])*"|/\*.*\*/|//[^\r]*) (если вы не смогли догадаться, то это выделение комментариев в С-подобном языке). Характерно, что регулярные выражения являются довольно слабым средством разбора текста, так как позволяют разбирать только регулярные (нерекурсивные) грамматики. Например, с их помощью невозможно полноценно разобрать XML или HTML.
Каковы же причины того, что регулярные выражения до такой степени нечитаемы, но при этом так популярны? Основная причина нечитаемости – в них отсутствуют средства абстрагирования, и более того, выражения приходится записывать одной монолитной строкой. Естественно, в таких условиях более-менее сложный образец превращается в кашу. А популярны они, по всей видимости, потому, что являются классическим и стандартным встроенным DSL. Как уже говорилось, они доступны где угодно, причем не просто доступны – они находятся "в шаговой доступности". На вопрос "почему не работает мое регулярное выражение" довольно легко найти ответ на любом программистском форуме. Получается парадокс – нечитаемый язык с плохими возможностями отладки, но очень доступный, вызывает массу проблем, но при этом все равно массово используется. Почему же ежики плачут, колются, но продолжают кушать кактус? Возможно, причина в том, что регулярным выражениям просто нет альтернативы?
Альтернатива, конечно, есть. Любой программист, окончивший любой ВУЗ, проходил курс формальных грамматик и знает, что существуют такие вещи, как контекстно-свободные грамматики и утилиты-генераторы парсеров, использующие более мощный язык (обычно BNF или EBNF). Такие генераторы парсеров построены на весьма изученных современной наукой методах, быстры и значительно мощнее регулярных выражений. Но на практике их используют редко даже по прямому назначению – для генерирования парсеров полноценных языков программирования.
Почему же парсеры на основе BNF/EBNF не используются там, где сейчас используются регулярные выражения? Одна из причин – такие парсеры несколько более сложны. Они требуют отдельного выделения токенов, что фактически аналогично возможностям регулярных выражений, и уже только потом – описания самой грамматики. Но нам кажется, что это мелкая и уж точно не главная причина. Основных причин две. Первая – требование более высокой квалификации программиста, а вторая, и, возможно, главная – то, что такие парсеры трудно использовать как встроенные средства. Использование регулярных выражений из языка программирования обычно сводится либо к вызову функции, либо к использованию встроенной прямо в язык (как в Perl) поддержки. Если такой поддержки или функции нет, то время, затрачиваемое программистом на создание нужного ему окружение, равно (а чаще превышает) время, которое потребуется программисту для ручного разбора нужных данных. В этом случае начинают работать естественные факторы – лень и желание избежать объемной непродуктивной работы. Программисты просто выбирают обходные пути, либо вообще избавляясь от разбора текста, или делая его кое-как. В общем, таких парсеров нет, и встроить их в языки общего назначения тяжело.
Относительно недавно появилась работа некоего Брайена Форда (Bryan Ford), посвященная его алгоритму, названному "packrat parsing". Он вытащил на свет формализм, разработанный около 30 лет назад, и описывавший парсер, использующий алгоритм нисходящего спуска с откатами (Top-Down Parsing Language, TDPL). Этот формализм позволяет описывать практически любой язык с одним ограничением – у этого языка может быть только одно дерево разбора, то есть он не может быть неоднозначным. Под это описание подходит практически любой компьютерный язык (в отличие от человеческих, неоднозначных по природе). В те далекие времена было научно доказано, что этот метод разбора может привести к экспоненциальному росту времени разбора. Алгоритм packrat за счет мемоизации промежуточных результатов позволил добиться линейного времени разбора. Однако на практике и без данной оптимизации этот алгоритм показывает весьма высокую производительность, по крайней мере не меньшую, чем скорость многих библиотек регулярных выражений, например, в .NET. В качестве формализма для описания TDPL Форд использовал PEG. Так вот PEG очень близок к регулярным выражениям, но при этом имеет средства абстрагирования и позволяет описывать рекурсивные грамматики. Его можно использовать в точно так же как регулярные выражения (поместив парсер в функцию или встроив его поддержку в язык программирования общего назначения). Более того, первые ласточки его использования уже есть – создана библиотека LPEG, которая позиционируется как замена регулярных выражений для языка Lua. Однако надеяться на победоносное шествие PEG по господствующим языкам и фреймворкам (Java, .NET, C++) не приходится. Почему? Вернитесь к началу сообщения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: PEG vs RegExp
От: Cris Украина  
Дата: 30.06.10 19:32
Оценка: -2
Здравствуйте, VladD2, Вы писали:

VD>Есть мнение, что новые научные теории побеждают только тогда, когда вымирают сторонники старых теорий. Удивительно, но с совершенно практическими вещами дело обстоит точно так же. Возьмем, например, такую распространенную вещь, как регулярные выражения. Они поддерживаются практически везде, библиотеки или фреймворки, поддерживающие регулярные выражения, написаны практически для всех языков программирования. При этом за последние два десятилетия регулярные выражения мало изменились. В частности, они как были, так и остались "write only" – будучи единожды написанными, они практически не поддаются прочтению. Оно и понятно, не так ведь просто догадаться, что делает набор из палочек и скобочек типа ("(\\"|\\\\|[^"])*"|/\*.*\*/|//[^\r]*) (если вы не смогли догадаться, то это выделение комментариев в С-подобном языке). Характерно, что регулярные выражения являются довольно слабым средством разбора текста, так как позволяют разбирать только регулярные (нерекурсивные) грамматики. Например, с их помощью невозможно полноценно разобрать XML или HTML.

VD>Каковы же причины того, что регулярные выражения до такой степени нечитаемы, но при этом так популярны? Основная причина нечитаемости – в них отсутствуют средства абстрагирования, и более того, выражения приходится записывать одной монолитной строкой. Естественно, в таких условиях более-менее сложный образец превращается в кашу. А популярны они, по всей видимости, потому, что являются классическим и стандартным встроенным DSL. Как уже говорилось, они доступны где угодно, причем не просто доступны – они находятся "в шаговой доступности". На вопрос "почему не работает мое регулярное выражение" довольно легко найти ответ на любом программистском форуме. Получается парадокс – нечитаемый язык с плохими возможностями отладки, но очень доступный, вызывает массу проблем, но при этом все равно массово используется. Почему же ежики плачут, колются, но продолжают кушать кактус? Возможно, причина в том, что регулярным выражениям просто нет альтернативы?
VD>Альтернатива, конечно, есть. Любой программист, окончивший любой ВУЗ, проходил курс формальных грамматик и знает, что существуют такие вещи, как контекстно-свободные грамматики и утилиты-генераторы парсеров, использующие более мощный язык (обычно BNF или EBNF). Такие генераторы парсеров построены на весьма изученных современной наукой методах, быстры и значительно мощнее регулярных выражений. Но на практике их используют редко даже по прямому назначению – для генерирования парсеров полноценных языков программирования.
VD>Почему же парсеры на основе BNF/EBNF не используются там, где сейчас используются регулярные выражения? Одна из причин – такие парсеры несколько более сложны. Они требуют отдельного выделения токенов, что фактически аналогично возможностям регулярных выражений, и уже только потом – описания самой грамматики. Но нам кажется, что это мелкая и уж точно не главная причина. Основных причин две. Первая – требование более высокой квалификации программиста, а вторая, и, возможно, главная – то, что такие парсеры трудно использовать как встроенные средства. Использование регулярных выражений из языка программирования обычно сводится либо к вызову функции, либо к использованию встроенной прямо в язык (как в Perl) поддержки. Если такой поддержки или функции нет, то время, затрачиваемое программистом на создание нужного ему окружение, равно (а чаще превышает) время, которое потребуется программисту для ручного разбора нужных данных. В этом случае начинают работать естественные факторы – лень и желание избежать объемной непродуктивной работы. Программисты просто выбирают обходные пути, либо вообще избавляясь от разбора текста, или делая его кое-как. В общем, таких парсеров нет, и встроить их в языки общего назначения тяжело.
VD>Относительно недавно появилась работа некоего Брайена Форда (Bryan Ford), посвященная его алгоритму, названному "packrat parsing". Он вытащил на свет формализм, разработанный около 30 лет назад, и описывавший парсер, использующий алгоритм нисходящего спуска с откатами (Top-Down Parsing Language, TDPL). Этот формализм позволяет описывать практически любой язык с одним ограничением – у этого языка может быть только одно дерево разбора, то есть он не может быть неоднозначным. Под это описание подходит практически любой компьютерный язык (в отличие от человеческих, неоднозначных по природе). В те далекие времена было научно доказано, что этот метод разбора может привести к экспоненциальному росту времени разбора. Алгоритм packrat за счет мемоизации промежуточных результатов позволил добиться линейного времени разбора. Однако на практике и без данной оптимизации этот алгоритм показывает весьма высокую производительность, по крайней мере не меньшую, чем скорость многих библиотек регулярных выражений, например, в .NET. В качестве формализма для описания TDPL Форд использовал PEG. Так вот PEG очень близок к регулярным выражениям, но при этом имеет средства абстрагирования и позволяет описывать рекурсивные грамматики. Его можно использовать в точно так же как регулярные выражения (поместив парсер в функцию или встроив его поддержку в язык программирования общего назначения). Более того, первые ласточки его использования уже есть – создана библиотека LPEG, которая позиционируется как замена регулярных выражений для языка Lua. Однако надеяться на победоносное шествие PEG по господствующим языкам и фреймворкам (Java, .NET, C++) не приходится. Почему? Вернитесь к началу сообщения.
статья классная... я даже не то что не находил альтернативы регулярных выражений, а даже не мог подумать что стоит поискать...
вперед на habrahabr
Re: PEG vs RegExp
От: Jack128  
Дата: 30.06.10 19:42
Оценка:
Здравствуйте, VladD2, Вы писали:

Ненавижу регулярки. 100 раз себя пытался заставить изучать на более менее прилично уровне — все без толку,этот синтаксис мя просто убивает.
Re: PEG vs RegExp
От: olegkr  
Дата: 30.06.10 19:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Почему? Вернитесь к началу сообщения.

Все гораздо проще. Я, например, никогда не слышал про PEG. Думаю таких, как я, большинство. Благодаря форуму узнал и буду пробовать. И никакой интриги.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.06.10 20:00
Оценка: +2
Здравствуйте, VladD2, Вы писали:

Красиво написано, но непонятно к чему.

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

Только кроме самой возможности в Nemerle, еще хотелось бы видеть реюзабельную библиотеку для .NET (иначе смысла нет) и какой-нить killer app, демонстрирующий фичу.
Re: PEG vs RegExp
От: Mazay Россия  
Дата: 30.06.10 20:07
Оценка:
Здравствуйте, VladD2, Вы писали:

Некоторые товарищи весьма тепло отзываются о библиотеке Boost.Spirit:

http://dvinogradov.blogspot.com/2010/03/boostspirit-in-practice.html
http://dvinogradov.blogspot.com/2009/06/fast-parsing.html

Она реализует парсер EBNF. Причем в компайлтайме. Несмотря на несколько покореженный синтаксис вполне удобна.

❝ Некоторые люди, во время решения одной проблемы думают: «Я знаю, я буду использовать регулярные выражения». Теперь у них две проблемы… ❞— Jamie Zawinski
А кому надо — пользуют нормальные парсеры.
Главное гармония ...
Re[2]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 20:24
Оценка:
Здравствуйте, olegkr, Вы писали:

VD>>Почему? Вернитесь к началу сообщения.

O>Все гораздо проще. Я, например, никогда не слышал про PEG. Думаю таких, как я, большинство. Благодаря форуму узнал и буду пробовать. И никакой интриги.

Проблема в том что пробовать не чего (ну, если конечно ты не собираешся пересесть на Nemerle или Lua). И, что самое обидное, вряд ли появится в ближайшее время? Почему? Вернись к началу сообщения
Автор: VladD2
Дата: 30.06.10
.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: PEG vs RegExp
От: olegkr  
Дата: 30.06.10 20:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Только кроме самой возможности в Nemerle, еще хотелось бы видеть реюзабельную библиотеку для .NET (иначе смысла нет) и какой-нить killer app, демонстрирующий фичу.

Оно есть
http://code.google.com/p/peg-sharp/

Насколько оно юзабельно — сейчас выясняю. Киллер фича — рекурсия и то, что PEG действительно можно читать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[3]: PEG vs RegExp
От: olegkr  
Дата: 30.06.10 20:26
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Проблема в том что пробовать не чего

Есть peg sharp, его и пробую.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re: PEG vs RegExp
От: dotneter  
Дата: 30.06.10 20:26
Оценка:
Здравствуйте, VladD2, Вы писали:

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

99% — никак не связаных с каким либо разбором текста.

0.9% — текст, но либо что то простое что вполне укладывается в несложный регексп
>Например, с их помощью невозможно полноценно разобрать XML или HTML.
либо для данного формата уже есть тонна библиотек для его разбора, кому нужно писать свой парсер html?

0.1% — да вот эти самые задачи для PEG, 0.09% который наверное можно решить существующими инструментами типа ANTLR.

Итого остается 0.01%
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[2]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 20:29
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Красиво написано, но непонятно к чему.


Пользуясь случаем — спасибо за редактирование Михаилу Купаеву.

G>Считаете что PEG лучше Regexp, так сделайте и не оглядывайтесь на чужие мнения.


Сделал(и)

G>Только кроме самой возможности в Nemerle, еще хотелось бы видеть реюзабельную библиотеку для .NET (иначе смысла нет) и какой-нить killer app, демонстрирующий фичу.


"Реюзабельная библиотека в дотнете" требует совсем другого объема работы и при этом еще и не обеспечивает того же удобства и скорости как то что сделано в немерле на коленке. Но это уже другая история.

В общем, моя задача — обратить внимание на проблему других с тем, чтобы эти другие решили проблему для их любимых языков. Мы даже создали отличный прототип этого дела. Осталось передать эстафету .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 20:32
Оценка:
Здравствуйте, Mazay, Вы писали:

M>Некоторые товарищи весьма тепло отзываются о библиотеке Boost.Spirit:


M>http://dvinogradov.blogspot.com/2010/03/boostspirit-in-practice.html

M>http://dvinogradov.blogspot.com/2009/06/fast-parsing.html

M>Она реализует парсер EBNF. Причем в компайлтайме. Несмотря на несколько покореженный синтаксис вполне удобна.


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

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

M>❝ Некоторые люди, во время решения одной проблемы думают: «Я знаю, я буду использовать регулярные выражения». Теперь у них две проблемы… ❞— Jamie Zawinski


Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 20:34
Оценка:
Здравствуйте, olegkr, Вы писали:

VD>>Проблема в том что пробовать не чего

O>Есть peg sharp, его и пробую.

Интересно! Не слшал о нем до этого.

Будут результаты — поделись ими.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 20:37
Оценка:
Здравствуйте, olegkr, Вы писали:

VD>>Проблема в том что пробовать не чего

O>Есть peg sharp, его и пробую.

Поглядел... Это очередной внешний генератор (если я правильно понял). Особым минусом является semantic actions задаваемые в конце правил (после апострофа). Это вряд ли может конкурировать с регексами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.06.10 20:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>"Реюзабельная библиотека в дотнете" требует совсем другого объема работы и при этом еще и не обеспечивает того же удобства и скорости как то что сделано в немерле на коленке. Но это уже другая история.

А тогда какой смысл? Пока не будет возможности написать что-то вроде Regex.Replace нету смысла обсуждать что лучше, не сопоставим уровень трудозатрат и получаемого эффекта.

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


имхо тут кроется наибольшая проблема немерелистов, вы не занимаетесь популяризацией nemerle.
Страуструп, Гослинг, Кей, ван Россум, Вирт, они все сами продвигали свои творения, а не ждали кому бы "передать эстафету".
Re[2]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 20:41
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Имхо, главная причина, мало кому нужно.

D>Предположим задачи среднестатистического программиста разбиты так.

D>99% — никак не связаных с каким либо разбором текста.


D>0.9% ...


И как при этом регексы появились?

Может быть проблема в том, что проблема которая составляет 0.9% от основной задачи начинает занимать 20% времени всей разработки при решении ее без соответствующих средств?

А если так, то почему не использовать более мощные и удобные средства для того же самого?

>>Например, с их помощью невозможно полноценно разобрать XML или HTML.

D>либо для данного формата уже есть тонна библиотек для его разбора, кому нужно писать свой парсер html?

Зайди на форум по дотнету погляди сколько людей пытается парсить ХМЛ/ХТМЛ с помощью регексов.

D>0.1% — да вот эти самые задачи для PEG, 0.09% который наверное можно решить существующими инструментами типа ANTLR.


Про ANTLR написано в тематическом сообщении.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 20:45
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А тогда какой смысл? Пока не будет возможности написать что-то вроде Regex.Replace нету смысла обсуждать что лучше, не сопоставим уровень трудозатрат и получаемого эффекта.


Чтобы "Regex.Replace()" сначала нужно написать "class Regex ...". Это уже сделано... для Regex...
Еще вопросы?

G>имхо тут кроется наибольшая проблема немерелистов, вы не занимаетесь популяризацией nemerle.


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

G>Страуструп, Гослинг, Кей, ван Россум, Вирт, они все сами продвигали свои творения, а не ждали кому бы "передать эстафету".


PEG не моя идея. Я ее увидел, воспользовался и рассказал окружающим. Не понимаю почему меня при этом в чем-то бвиняют.
И главное... не понимаю причем тут Немерле?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: PEG vs RegExp
От: olegkr  
Дата: 30.06.10 20:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Поглядел... Это очередной внешний генератор (если я правильно понял). Особым минусом является semantic actions задаваемые в конце правил (после апострофа). Это вряд ли может конкурировать с регексами.

Есть такое. Без особой необходимости пользоваться не захочется.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[3]: PEG vs RegExp
От: dotneter  
Дата: 30.06.10 20:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И как при этом регексы появились?

Администраторам юникс систем нужен был иструмен для работы с текстом, а потом худо бедно перекочивал в программирование взяв с собой проблеммы однострочности, понимаемости и сопровождения.
VD>Может быть проблема в том, что проблема которая составляет 0.9% от основной задачи начинает занимать 20% времени всей разработки при решении ее без соответствующих средств?
Сомневаюсь.

VD>А если так, то почему не использовать более мощные и удобные средства для того же самого?

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

VD>Зайди на форум по дотнету погляди сколько людей пытается парсить ХМЛ/ХТМЛ с помощью регексов.

Я думаю эти люди не справяться с пегом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[5]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.06.10 20:53
Оценка:
Здравствуйте, VladD2, Вы писали:

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


G>>А тогда какой смысл? Пока не будет возможности написать что-то вроде Regex.Replace нету смысла обсуждать что лучше, не сопоставим уровень трудозатрат и получаемого эффекта.


VD>Чтобы "Regex.Replace()" сначала нужно написать "class Regex ...". Это уже сделано... для Regex...

VD>Еще вопросы?
Ага, кто будет писать?

G>>имхо тут кроется наибольшая проблема немерелистов, вы не занимаетесь популяризацией nemerle.


VD>Мне казалось мы о PEG назговариваем.

Пока реализация peg в более пригодном виде есть только в Nemerle (хотя есть парсер-комбинаторы в других языках).


G>>Страуструп, Гослинг, Кей, ван Россум, Вирт, они все сами продвигали свои творения, а не ждали кому бы "передать эстафету".


VD>PEG не моя идея. Я ее увидел, воспользовался и рассказал окружающим.

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


VD>Не понимаю почему меня при этом в чем-то бвиняют. И главное... не понимаю причем тут Немерле?

При том что единственный способ популяризировать идею — воплотить её в жизнь.
Re: PEG vs RegExp
От: dotneter  
Дата: 30.06.10 20:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Оно и понятно, не так ведь просто догадаться, что делает набор из палочек и скобочек типа ("(\\"|\\\\|[^"])*"|/\*.*\*/|//[^\r]*)

А как будет выглядеть решение на Немерле со встроенным пегом?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[6]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 20:56
Оценка:
Здравствуйте, olegkr, Вы писали:

VD>>Поглядел... Это очередной внешний генератор (если я правильно понял). Особым минусом является semantic actions задаваемые в конце правил (после апострофа). Это вряд ли может конкурировать с регексами.

O>Есть такое. Без особой необходимости пользоваться не захочется.

Ага. А меж тем то как обойти эти проблемы уже придумано в процессе работы над peg-парсером для немерла и думах о будущем макросистемы немерла. Все это можно воспроизвести и для дотнета. Вопрос в том, что это немалый объем работы который нужно проделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 21:01
Оценка:
Здравствуйте, gandjustas, Вы писали:

VD>>Чтобы "Regex.Replace()" сначала нужно написать "class Regex ...". Это уже сделано... для Regex...

VD>>Еще вопросы?
G>Ага, кто будет писать?

Точно не я. У меня планы на 3 года вперед прописаны.

G>Пока реализация peg в более пригодном виде есть только в Nemerle (хотя есть парсер-комбинаторы в других языках).


Тоже решение. Не очень эффективное, но лучше чем ничего.

VD>>PEG не моя идея. Я ее увидел, воспользовался и рассказал окружающим.

G>Все послушали, согласились и продолжили использовать regex, а потом выросло следующее поколение разработчиков, которое кроме regex ничего и не знает.

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

VD>>Не понимаю почему меня при этом в чем-то бвиняют. И главное... не понимаю причем тут Немерле?

G>При том что единственный способ популяризировать идею — воплотить её в жизнь.

Ну, почему же о ней можно еще сказать. Воплощать в жизнь я ее не буду. По крайне мере на уровне библиотеки для дотнета (явы или С++). В конце концов для меня она уже доступна. И я ее использую все больше и больше. Вот сейчас я хочу повторить ХМЛ-литералы из Васика (только с расширенной функциональностью). Для этого я уже воспользовался PEG-парсером (макросом). Полет нормальный. Уже вижу что можно улучшить .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: PEG vs RegExp
От: olegkr  
Дата: 30.06.10 21:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ага. А меж тем то как обойти эти проблемы уже придумано в процессе работы над peg-парсером для немерла и думах о будущем макросистемы немерла. Все это можно воспроизвести и для дотнета. Вопрос в том, что это немалый объем работы который нужно проделать.

Я вот так сходу не соображаю, а в чем собственно проблемы состоят? Зачем генерить файлы?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 21:07
Оценка:
Здравствуйте, dotneter, Вы писали:

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


VD>>И как при этом регексы появились?

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

Если под "Администраторами юникса" ты понимаешь Кена Томпсона, то таки да .

VD>>Может быть проблема в том, что проблема которая составляет 0.9% от основной задачи начинает занимать 20% времени всей разработки при решении ее без соответствующих средств?

D>Сомневаюсь.

Не вижу ничего сомнительного. В прочем как и аргументации.

VD>>А если так, то почему не использовать более мощные и удобные средства для того же самого?

D>Мощность не дается бесплатна, ее нужно изучать а многие и регекспы не могут осилить.

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

VD>>Зайди на форум по дотнету погляди сколько людей пытается парсить ХМЛ/ХТМЛ с помощью регексов.

D>Я думаю эти люди не справяться с пегом.

А я думаю, справятся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: PEG vs RegExp
От: dotneter  
Дата: 30.06.10 21:07
Оценка: 3 (2)
Здравствуйте, VladD2, Вы писали:

VD>Первая – требование более высокой квалификации программиста, а вторая, и, возможно, главная – то, что такие парсеры трудно использовать как встроенные средства.

Квалификация и для Пег нужна.
А второе, ну например есть такие библиотеки как irony
public class ExpressionGrammar : Irony.Compiler.Grammar {
    public ExpressionGrammar() {
      // 1. Terminals
      Terminal n = new NumberTerminal("number");
      Terminal v = new IdentifierTerminal("variable");
 
      // 2. Non-terminals
      NonTerminal Expr = new NonTerminal("Expr");
      NonTerminal BinOp = new NonTerminal("BinOp");
      NonTerminal UnOp = new NonTerminal("UnOp");
      NonTerminal ExprLine = new NonTerminal("ExprLine");
 
      // 3. BNF rules
      Expr.Expression = n | v | Expr + BinOp + Expr | UnOp + Expr | 
                        "(" + Expr + ")";
      BinOp.Expression = Symbol("+") | "-" | "*" | "/" | "**";
      UnOp.Expression = "-";            //Irony provides default conversion here 
      ExprLine.Expression = Expr + Eof; //Eof is a predefined EOF terminal
      this.Root = ExprLine;             //Set grammar top element
 
      // 4. Set operators precedence and associativity
      RegisterOperators(1, "+", "-");
      RegisterOperators(2, "*", "/");
      RegisterOperators(3, Associativity.Right, "**");
 
      // 5. Register parenthesis as punctuation symbols
      //    so they will not appear in the syntax tree
      PunctuationSymbols.AddRange(new string[] { "(", ")" });

    }
    
     ExpressionGrammar grammar = new ExpressionGrammar();
  LanguageCompiler compiler = new LanguageCompiler(grammar);

  string expr = "a + b * 3.14 / (2.0 * x + y**z**2)";
  AstNode rootNode = compiler.Parse(expr);
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[8]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 21:07
Оценка:
Здравствуйте, olegkr, Вы писали:

O>Я вот так сходу не соображаю, а в чем собственно проблемы состоят? Зачем генерить файлы?


Какие файлы?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: PEG vs RegExp
От: olegkr  
Дата: 30.06.10 21:09
Оценка: +2
Здравствуйте, dotneter, Вы писали:

D>Мощность не дается бесплатна, ее нужно изучать а многие и регекспы не могут осилить.

Что любопытно, мне синтаксис PEG-а показался более простым и удобным для "осиления".
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[9]: PEG vs RegExp
От: olegkr  
Дата: 30.06.10 21:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Какие файлы?

Сишарповые.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[5]: PEG vs RegExp
От: dotneter  
Дата: 30.06.10 21:11
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Если под "Администраторами юникса" ты понимаешь Кена Томпсона, то таки да .

Several utilities provided by Unix distributions—including the editor ed and the filter grep—were the first to popularize the concept of regular expressions.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[7]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.06.10 21:15
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Чтобы "Regex.Replace()" сначала нужно написать "class Regex ...". Это уже сделано... для Regex...

VD>>>Еще вопросы?
G>>Ага, кто будет писать?
VD>Точно не я. У меня планы на 3 года вперед прописаны.
Жаль.

G>>Пока реализация peg в более пригодном виде есть только в Nemerle (хотя есть парсер-комбинаторы в других языках).

VD>Тоже решение. Не очень эффективное, но лучше чем ничего.
Да, эффективность отставляет желать лучшего. В haskell еще ниче так, а в том же C# и F# крайне медленно работает без оптимизаций.

VD>>>PEG не моя идея. Я ее увидел, воспользовался и рассказал окружающим.

G>>Все послушали, согласились и продолжили использовать regex, а потом выросло следующее поколение разработчиков, которое кроме regex ничего и не знает.

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


Я думаю раньше Microsoft со своим M подоспеет.
Re[2]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 21:27
Оценка:
Здравствуйте, dotneter, Вы писали:

VD>>Оно и понятно, не так ведь просто догадаться, что делает набор из палочек и скобочек типа ("(\\"|\\\\|[^"])*"|/\*.*\*/|//[^\r]*)

D>А как будет выглядеть решение на Немерле со встроенным пегом?
Как-то так:
singleLineComment  = "//" (!'\r' any)* newLine?; // newLine необезательный так как комментарий может находиться в конце файла
delimitedComment   = "/*" (!"*/" any)* "*/";
comment            = singleLineComment / delimitedComment;
regularString      = '"' (!('\"' / @"\\") any)* '"';
result             = comment / regularString;
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 21:31
Оценка:
Здравствуйте, olegkr, Вы писали:

VD>>Какие файлы?

O>Сишарповые.

Это ты о peg sharp? Ну, дык это классический генератор парсеров. Он генерирует код который потом компилируется в исполнимый. Это обеспечивает более высокую скорость нежели если бы код итерпретировался бы. ХмлСериалайзер поступает так же.

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

В немерле для генерации кода используются макросы. Это в разы проще генерации файлов и дает возможность встроить код прямо внутрь кода основного проекта (на немерле). В шарпе такой возможности нет. Вот и генерят файлы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: шило vs мыло
От: Wolverrum Ниоткуда  
Дата: 30.06.10 21:31
Оценка:
Попробовал с ходу откопать хоть один свой проект со "страшными write-only регулярками", так оказалось, что они, противные, автоматом строятся везде. Вот незадача...

Исходя из своей практики работы с текстами, Влад, а она у меня, в основном, касается текстов на ЕЯ, могу заявить, что регулярок, причем "классических" (т.е. практически в рамках (*+) ) обычно хватает "с головой" (в случае анализа ЕЯ-корпусов — это еще и банально "дешевле", иногда, конечно же). Более мощные формализмы приходилось привлекать достаточно редко. Ессно, анализировать парные скобки и прочие не-автоматные языки регулярками — это, имхо, аццкий моветон, и я полностью согласен с тобой в этом пункте. Но и подобные задачи в целом встречаются гораздо реже, чем ты пытаешься представить в посте. В принципе, вид с твоей колокольни мне понятен: для средств разработки формальные грамматики и сопутствующие инструменты просто необходимы как воздух, но одними средствами разработки мир не ограничен, а там все как-то больше на более простых структурах повязано (как правило). Ну и еще один, видимо, самый важный аспект — отсутствие системной подготовки. Без нее, родимой, даже РВ тяжко воспринимаются.
Re[8]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 21:35
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Да, эффективность отставляет желать лучшего. В haskell еще ниче так, а в том же C# и F# крайне медленно работает без оптимизаций.


Дык Хаскель много лет вылизывали оптимизируя комбинирование функций. Но выше крыши не прыгнишь. Плюс алгоритм там самый что ни на есть дубовый (пербор с откатами) и тут уже ничего не оптимизируешь. Вот в макросах или внешнем генераторе кода оптимизировать можно. Например, сгенерировать ДКА для нетерминалов (надеюсь я на понятном языке говорю?).

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


G>Я думаю раньше Microsoft со своим M подоспеет.


Блажен кто верует .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 21:37
Оценка:
Здравствуйте, dotneter, Вы писали:

VD>>Если под "Администраторами юникса" ты понимаешь Кена Томпсона, то таки да .

D>Several utilities provided by Unix distributions—including the editor ed and the filter grep—were the first to popularize the concept of regular expressions.

Ну? Проблемы перевода?

Цитирую по буквам "включил в вой редактор и filter grep—were". Кен не администратор, а программист. Ну, а концепции были вообще математиками заложены.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 21:38
Оценка:
Здравствуйте, olegkr, Вы писали:

O>Что любопытно, мне синтаксис PEG-а показался более простым и удобным для "осиления".


Таже фигня. Немного более многословным, но это как раз та многословность которая повышает читабельность, а не понижает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: PEG vs RegExp
От: dotneter  
Дата: 30.06.10 21:42
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну? Проблемы перевода?


VD>Цитирую по буквам "включил в вой редактор и filter grep—were". Кен не администратор, а программист. Ну, а концепции были вообще математиками заложены.


the first to popularize the concept of regular expressions.
что первоначально пополяризировало концепцию регекспов.

Я верю что их придумал программист, но сначало они нашли применение не в программировании.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[11]: PEG vs RegExp
От: olegkr  
Дата: 30.06.10 21:57
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В шарпе такой возможности нет. Вот и генерят файлы.

Однако извратились.
http://www.codeproject.com/KB/recipes/grammar_support_1.aspx
class IntSum_C3 : PegCharParser
{
   public IntSum_C3(string s) : base(s) { }
   public bool Sum()//Sum:    S [0-9]+  (S [+-] S [0-9]+)* S ;
   {
      return 
         And(()=>

            S()
         && PlusRepeat(()=>In('0','9'))
         && OptRepeat(()=> S() && OneOfChars('+','-') && S() && PlusRepeat(()=>In('0','9')))
     && S());
   }
   public bool S()//S:     [ \n\r\t\v]*            ;
   {
      return OptRepeat(()=>OneOfChars(' ', '\n', '\r', '\t', '\v'));
   }
}
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 22:09
Оценка:
Здравствуйте, olegkr, Вы писали:

VD>>Проблема в том что пробовать не чего

O>Есть peg sharp, его и пробую.

У этого орла и у нас есть один лассический пример — строчный калькулятор.
Для сравнения как это выглядит у нас:
CalcParser.n
использование: CalcTestes.n

И как это выглядит в peg-sharp:
Expressions.cs
Parser.peg
ParserHelpers.cs
Expression.cs
использование: Program.cs
файл сгенерированный построителем парсеров: Parser.cs


Плюс практически уверен, что наш вариант намного более быстр, так как не использует делегатов, не создает АСТ и вообще не делает лишних телодвижений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 22:12
Оценка:
Здравствуйте, olegkr, Вы писали:

VD>>В шарпе такой возможности нет. Вот и генерят файлы.

O>Однако извратились.

O>http://www.codeproject.com/KB/recipes/grammar_support_1.aspx


Это классический комбинаторный парсер. Проблема только в том, что на C# комбинаторы выглядят не очень хорошо и к тому же работают очень медленно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: PEG vs RegExp
От: olegkr  
Дата: 30.06.10 22:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Можно было бы конечно генерировать напрямую МСИЛ, но это во много раз сложнее.

Можно, кстати, и не генерить MSIL напрямую. Взять те же исходники, что они генерят и компильнуть в память (это легко).
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Re[12]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.06.10 23:38
Оценка:
Здравствуйте, olegkr, Вы писали:

VD>>Можно было бы конечно генерировать напрямую МСИЛ, но это во много раз сложнее.

O>Можно, кстати, и не генерить MSIL напрямую. Взять те же исходники, что они генерят и компильнуть в память (это легко).

Жаль только что компилятор шарпа пока что — это анменеджед-приложение и в памяти он компилировать не умеет (только с диска). Но компьютеры нонче шустрые .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 04:32
Оценка: 2 (1)
Здравствуйте, VladD2, Вы писали:

M>>Она реализует парсер EBNF. Причем в компайлтайме. Несмотря на несколько покореженный синтаксис вполне удобна.


VD>Насколько я понимаю она использует похожий алгоритм рекурсивного спуска. Но думаю что без откатов.

И почему ты так думаешь?
Откаты там были с самой первой версии: кому нужен рекурсивный спуск без откатов

VD>Ну, а огромной проблемой этой библиотеки является средство реализации.


Прям так уже и "огромной" Под средством реализации имеется в виду сам язык С++? Тогда это какая-то странная претензия — библиотека же для С++
Под "огромностью" проблемы обычно подразумевается практическая невозможность использования либо ее крайняя сложность. Ни того, ни другого я в Спирите не наблюдаю.

VD>Простенькие примеры выливаются в сотни мег занятого места на диске.



можно пример "простенького примера" на "сотни мег"?

вот простенький пример из документации:
http://www.boost.org/doc/libs/1_43_0/libs/spirit/doc/html/spirit/qi/tutorials/mini_xml___asts_.html, и где тут "сотни мег"?

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

Вот, например, парсер формата JSON из библиотеки Boost.PropertyTree, причем написанный на старом Spirit, который более многословен:
https://svn.boost.org/trac/boost/browser/trunk/boost/property_tree/detail/json_parser_read.hpp#L193

Если ты вдруг о размерах бинарника — вот я только что скомпилировал пример калькулятора boost-1.38.0/libs/spirit/classic/example/fundamental/full_calc.cpp (причем компилировал стареньким gcc 3.4.6) — получился бинарник размером 33к. Где "сотни мег" — не пойму.

Да, еще стандартная претензия — время компиляции, так вот оно, время на компиляцию этого примера, компилятор тот же:
real 0m1.438s
user 0m1.070s
sys 0m0.124s
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: PEG vs RegExp
От: alexeiz  
Дата: 01.07.10 04:54
Оценка:
Здравствуйте, olegkr, Вы писали:

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


G>>Только кроме самой возможности в Nemerle, еще хотелось бы видеть реюзабельную библиотеку для .NET (иначе смысла нет) и какой-нить killer app, демонстрирующий фичу.

O>Оно есть
O>http://code.google.com/p/peg-sharp/

O>Насколько оно юзабельно — сейчас выясняю. Киллер фича — рекурсия и то, что PEG действительно можно читать.


Regex'ы тоже в последнее время возможны рекурсивные и их тоже можно читать, по крайней мере в Perl 5.10:
qr {
   (?(DEFINE)
     (?<address>         (?&mailbox) | (?&group))
     (?<mailbox>         (?&name_addr) | (?&addr_spec))
     (?<name_addr>       (?&display_name)? (?&angle_addr))
     (?<angle_addr>      (?&CFWS)? < (?&addr_spec) > (?&CFWS)?)
     (?<group>           (?&display_name) : (?:(?&mailbox_list) | (?&CFWS))? ;
                                            (?&CFWS)?)
     (?<display_name>    (?&phrase))
     (?<mailbox_list>    (?&mailbox) (?: , (?&mailbox))*)
     (?<address_list>    (?&address) (?: , (?&address))*)
     (?<addr_spec>       (?&local_part) \@ (?&domain))
     (?<local_part>      (?&dot_atom) | (?&quoted_string))
     (?<domain>          (?&dot_atom) | (?&domain_literal))
     (?<domain_literal>  (?&CFWS)? \[ (?: (?&FWS)? dcontent)* (?&FWS)?
                                   \] (?&CFWS)?)
     (?<dcontent>        (?&dtext) | (?&quoted_pair))
     (?<dtext>           (?&NO_WS_CTL) | [\x21-\x5a\x5e-\x7e])
     (?<atext>           (?&ALPHA) | (?&DIGIT) | [!#\$%&'*+-/=?^_`{|}~])
     (?<atom>            (?&CFWS)? (?&atext)+ (?&CFWS)?)
     (?<dot_atom>        (?&CFWS)? (?&dot_atom_text) (?&CFWS)?)
     (?<dot_atom_text>   (?&atext)+ (?: \. (?&atext)+)*)
     (?<text>            [\x01-\x09\x0b\x0c\x0e-\x7f])
     (?<quoted_pair>     \\ (?&text))
     (?<qtext>           (?&NO_WS_CTL) | [\x21\x23-\x5b\x5d-\x7e])
     (?<qcontent>        (?&qtext) | (?&quoted_pair))
     (?<quoted_string>   (?&CFWS)? (?&DQUOTE) (?:(?&FWS)? (?&qcontent))*
                          (?&FWS)? (?&DQUOTE) (?&CFWS)?)
     (?<word>            (?&atom) | (?&quoted_string))
     (?<phrase>          (?&word)+)
     # Folding white space
     (?<FWS>             (?: (?&WSP)* (?&CRLF))? (?&WSP)+)
     (?<ctext>           (?&NO_WS_CTL) | [\x21-\x27\x2a-\x5b\x5d-\x7e])
     (?<ccontent>        (?&ctext) | (?&quoted_pair) | (?&comment))
     (?<comment>         \( (?: (?&FWS)? (?&ccontent))* (?&FWS)? \) )
     (?<CFWS>            (?: (?&FWS)? (?&comment))*
                         (?: (?:(?&FWS)? (?&comment)) | (?&FWS)))
     # No whitespace control
     (?<NO_WS_CTL>       [\x01-\x08\x0b\x0c\x0e-\x1f\x7f])
     (?<ALPHA>           [A-Za-z])
     (?<DIGIT>           [0-9])
     (?<CRLF>            \x0d \x0a)
     (?<DQUOTE>          ")
     (?<WSP>             [\x20\x09])
   )
   (?&address)
}x;

А в Perl 6 они уже даже и выглядят элегантно.
Re[4]: PEG vs RegExp
От: night beast СССР  
Дата: 01.07.10 04:56
Оценка: +1
Здравствуйте, jazzer, Вы писали:

M>>>Она реализует парсер EBNF. Причем в компайлтайме. Несмотря на несколько покореженный синтаксис вполне удобна.


VD>>Насколько я понимаю она использует похожий алгоритм рекурсивного спуска. Но думаю что без откатов.

J>И почему ты так думаешь?
J>Откаты там были с самой первой версии: кому нужен рекурсивный спуск без откатов

VD>>Ну, а огромной проблемой этой библиотеки является средство реализации.


J>Прям так уже и "огромной" Под средством реализации имеется в виду сам язык С++? Тогда это какая-то странная претензия — библиотека же для С++

J>Под "огромностью" проблемы обычно подразумевается практическая невозможность использования либо ее крайняя сложность. Ни того, ни другого я в Спирите не наблюдаю.

немного забавно, но в данном случае вы с владом (если отбросить его нелюбовь к плюсам) воюете на одной стороне

собственно, цель поста -- донести пользу применения грамматик (и ПЕГ в частности) до общественности...
Re: PEG vs RegExp
От: ZevS Россия  
Дата: 01.07.10 07:03
Оценка:
А всего-то и нужно — убедить W3C использовать PEG в <xsd:pattern>
Re[3]: PEG vs RegExp
От: z00n  
Дата: 01.07.10 07:29
Оценка: 9 (3)
Здравствуйте, VladD2, Вы писали:

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


VD>>>Почему? Вернитесь к началу сообщения.

O>>Все гораздо проще. Я, например, никогда не слышал про PEG. Думаю таких, как я, большинство. Благодаря форуму узнал и буду пробовать. И никакой интриги.

VD>Проблема в том что пробовать не чего (ну, если конечно ты не собираешся пересесть на Nemerle или Lua). И, что самое обидное, вряд ли появится в ближайшее время? Почему? Вернись к началу сообщения
Автор: VladD2
Дата: 30.06.10
.


Это преувеличение:
— проект OMETA для C#, Javascript,Python, Ruby, Scheme, CL etc
— peg комбинаторный парсер входит в состав стандартной библиотеки Scala 2.8
— для Java их несколько штук (Rats, Mouse etc)
— для С, по крайней мере peg-leg: http://piumarta.com/software/peg/
— для C++ — PEG Template Library: http://code.google.com/p/pegtl/

Не всеми так же просто пользоваться, как LPEG или OMETA — но недостатка в парсерах определенно нет
Re[4]: PEG vs RegExp
От: anton_t Россия  
Дата: 01.07.10 07:30
Оценка:
Здравствуйте, alexeiz, Вы писали:

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


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


G>>>Только кроме самой возможности в Nemerle, еще хотелось бы видеть реюзабельную библиотеку для .NET (иначе смысла нет) и какой-нить killer app, демонстрирующий фичу.

O>>Оно есть
O>>http://code.google.com/p/peg-sharp/

O>>Насколько оно юзабельно — сейчас выясняю. Киллер фича — рекурсия и то, что PEG действительно можно читать.


A>Regex'ы тоже в последнее время возможны рекурсивные и их тоже можно читать, по крайней мере в Perl 5.10:

A>
A>qr {
A>   (?(DEFINE)
A>     (?<address>         (?&mailbox) | (?&group))
A>     (?<mailbox>         (?&name_addr) | (?&addr_spec))
A>     (?<name_addr>       (?&display_name)? (?&angle_addr))
A>     (?<angle_addr>      (?&CFWS)? < (?&addr_spec) > (?&CFWS)?)
A>     (?<group>           (?&display_name) : (?:(?&mailbox_list) | (?&CFWS))? ;
A>                                            (?&CFWS)?)
A>     (?<display_name>    (?&phrase))
A>     (?<mailbox_list>    (?&mailbox) (?: , (?&mailbox))*)
A>     (?<address_list>    (?&address) (?: , (?&address))*)
A>     (?<addr_spec>       (?&local_part) \@ (?&domain))
A>     (?<local_part>      (?&dot_atom) | (?&quoted_string))
A>     (?<domain>          (?&dot_atom) | (?&domain_literal))
A>     (?<domain_literal>  (?&CFWS)? \[ (?: (?&FWS)? dcontent)* (?&FWS)?
A>                                   \] (?&CFWS)?)
A>     (?<dcontent>        (?&dtext) | (?&quoted_pair))
A>     (?<dtext>           (?&NO_WS_CTL) | [\x21-\x5a\x5e-\x7e])
A>     (?<atext>           (?&ALPHA) | (?&DIGIT) | [!#\$%&'*+-/=?^_`{|}~])
A>     (?<atom>            (?&CFWS)? (?&atext)+ (?&CFWS)?)
A>     (?<dot_atom>        (?&CFWS)? (?&dot_atom_text) (?&CFWS)?)
A>     (?<dot_atom_text>   (?&atext)+ (?: \. (?&atext)+)*)
A>     (?<text>            [\x01-\x09\x0b\x0c\x0e-\x7f])
A>     (?<quoted_pair>     \\ (?&text))
A>     (?<qtext>           (?&NO_WS_CTL) | [\x21\x23-\x5b\x5d-\x7e])
A>     (?<qcontent>        (?&qtext) | (?&quoted_pair))
A>     (?<quoted_string>   (?&CFWS)? (?&DQUOTE) (?:(?&FWS)? (?&qcontent))*
A>                          (?&FWS)? (?&DQUOTE) (?&CFWS)?)
A>     (?<word>            (?&atom) | (?&quoted_string))
A>     (?<phrase>          (?&word)+)
A>     # Folding white space
A>     (?<FWS>             (?: (?&WSP)* (?&CRLF))? (?&WSP)+)
A>     (?<ctext>           (?&NO_WS_CTL) | [\x21-\x27\x2a-\x5b\x5d-\x7e])
A>     (?<ccontent>        (?&ctext) | (?&quoted_pair) | (?&comment))
A>     (?<comment>         \( (?: (?&FWS)? (?&ccontent))* (?&FWS)? \) )
A>     (?<CFWS>            (?: (?&FWS)? (?&comment))*
A>                         (?: (?:(?&FWS)? (?&comment)) | (?&FWS)))
A>     # No whitespace control
A>     (?<NO_WS_CTL>       [\x01-\x08\x0b\x0c\x0e-\x1f\x7f])
A>     (?<ALPHA>           [A-Za-z])
A>     (?<DIGIT>           [0-9])
A>     (?<CRLF>            \x0d \x0a)
A>     (?<DQUOTE>          ")
A>     (?<WSP>             [\x20\x09])
A>   )
A>   (?&address)
A>}x;
A>

A>А в Perl 6 они уже даже и выглядят элегантно.

Это уже не Regex получается, а парсер с контекстно-свободной грамматикой.
Re[2]: PEG vs RegExp
От: March_rabbit  
Дата: 01.07.10 07:44
Оценка:
Здравствуйте, Jack128, Вы писали:

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


J>Ненавижу регулярки. 100 раз себя пытался заставить изучать на более менее прилично уровне — все без толку,этот синтаксис мя просто убивает.

слабак
я так их довольно часто применяю, когда можно сделать довольно простое правило и быстро применить.
Re[3]: PEG vs RegExp
От: March_rabbit  
Дата: 01.07.10 07:45
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

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


VD>>>Почему? Вернитесь к началу сообщения.

O>>Все гораздо проще. Я, например, никогда не слышал про PEG. Думаю таких, как я, большинство. Благодаря форуму узнал и буду пробовать. И никакой интриги.

VD>Проблема в том что пробовать не чего (ну, если конечно ты не собираешся пересесть на Nemerle или Lua). И, что самое обидное, вряд ли появится в ближайшее время? Почему? Вернись к началу сообщения
Автор: VladD2
Дата: 30.06.10
.

ну и чем тогда весь тред? О том, что все бегом на немерле?
Re: PEG vs RegExp
От: mefrill Россия  
Дата: 01.07.10 07:54
Оценка: 170 (19)
Здравствуйте, VladD2, Вы писали:
VD>Есть мнение, что новые научные теории побеждают только тогда, когда вымирают сторонники старых теорий...

Есть несколько утверждений, на которые хотелось бы возразить. Но, чтобы быть понятым, сначала про историю возникновения регулярных выражений. Регулярные выражения придумал Клини для описания событий в нейронных сетях. Сами нейронные сети были придуманы Мак-Каллоком и Питтсом еще в 40-х годах прошлого века. Мак-Каллок был известный физиолог, а Питтс инженер. В Чикаго, куда Питтс с другом приехали работать в Университет, их по причине отсутствия крыши над головой приютин Мак-Каллок. Вечерами они трепались на всяческие темы, в результате родилась теория нейронных сетей. Питтс изучал то, что сейчас называется исчислением предикатов, у Тарского. Поэтому нейронные сети, как не дико это сейчас звучит, они описали посредством исчисления предикатов. Идея понравилась и этой проблематикой стали заниматься многие известные люди, в том числе и Марвин Минский. Последний даже в 50-х построил самообучающуюся машину на этих принципах. Сам подход моделирования нервной деятельности очень интересный, например, Мак-Каллок считал такую вещь, как абстракция, проявлением чисто физических свойств мозга -- в нейрон могут входить два входа от различных возбуждающих источников, поэтому просто не имеется способа в точности определить откуда пришло возбуждение. С самого начала было ясно, что нейронная сеть Мак-Каллок-Питтса представляет собой конечный автомат, т.е. что наш мозг представляет собой по сути конечный автомат. Так вот, в 50-х годах Клини выпустил статью, в которой предложил интересный способ описания событий в нейронных сетях Мак-Каллока-Питтса с помощью довольно простого языка. Сеть получает на вход данные посредством возбуждения входных сигналов, через некоторое время на выходя становятся активными некоторые выходные сигналы -- это и есть события. Клини пытался описать так называемые "регулярные" (regular, т.е. ординарные, обычные) события, т.е. те события, оторые могут происходить в таких сетях. Вот для описания регулярных событий и были придуманы специальные выражения, которые Клини также назвал "регулярными". Теорема об эквивалентности языков (да, каждое событие можн опредставить как цепочку некоторого языка, если поименовать входы сети символами некоторого алфавита) нейронных сетей и регулярных выражений, доказанная в этой статье, теперь так и называется "теорема Клини" и изучается в курсе по формальным языкам.

До конца 60-х годов регулярные выражения никого особо не интресовали. Но в конце 60-х Томпсон, разрабатывая программу текстового редактора, придумал как применить регулярные выражения для поиска в редактируемом тексте. На самом деле для поиска использовался конечный автомат, но теорема Клини об эквивалентности регулярных и автоматных языков, дала Томпсону возможность применить удобный инструмент регулярных выражений для создания таких поисковых автоматов. Этот подход оказался очень удобным и теперь используется повсеместно именно в таком контексте: для задания поисковых шаблонов.

Итак, регулярные выражения представляют собой удобный способ задания поисковых шаблонов и наиболее часто используются именно в этом качестве. Также удобно использовать регулярные выражения для задания языков лексических типов (чисел, идентификаторов, строк и т.п.) в лексических анализаторах. Конечно надо еще объяснить почему регулярные выражения удобны для поиска и лексического анализа. Мое мнение: единственное синтаксическое отношение, которое задают регулярные языки -- это отношение "быть рядом". Это самое "рядом" не обязательно непосредтсвенно рядом, но может быть установлено через некоторый шаблон, например, через нуль или более повторений некоторого символа: a (b*) c. Здесь a и c "рядом", но через регулярный язык b* = {epsilon, b, bb, bbb, ... }. Тким образом, регулярные выражения подходят для такого структурирования текста, при котором этот текст разбивается на простые составные части, находящиеся рядом.

Контекстно-свободные языки задают отношение иерархии, т.е. отношение "быть частью". Фактически, в классическом понимании КС-языка, его синтакасические свойства характеризуются категориально, т.е. КС-грамматика представляет собой категориальную грамматику. В этом подходе в грамматике выделяется конечное множество "каетгорий" или типов. Также имеется отношение иерархии, в котором некоторые категории могут быть составлены из других категорий. Нетерниманальные символы КС-грамматики часто еще называют "переменными" подчеркивая тем самым их категориальную интерпетацию. правила КС-грамматики задают отношение между категориями. A --> aBC говорит о том, что тип A может быть составлен из типов a, B и C, здесь терминальный символ также считается категорией, но особой "атомарной". Интересно, что у Хомского такой интерпретации не было, он рассматривал порождающие грамматики просто как программы генерации цепочек языка. Нынешний общепрнятый в программировании подход к интепретации КС-грамматики основан на "перевернутом рассмотрении": КС-грамматика рассматривается не как средство порождения, но как средство распознавания цепочек языка, их структурирования. С этой точки зрения, применение КС-грамматик для выражения отношения "быть рядом" выглядит излишним и ненужным усложнением. Видимо, поэтому КС-языки не приживаются для стуктурирования таких текстов.

Относительно невозможности вводить абстракции в регулярных выражениях. Это вполне возможно. Можно просто вводить переменные, обозначающие регулярные языки, т.е. алиасы регулярных выражений. Это довольно обычный подход, который используеются в таком известном инструменте, как Lex. Это так называемые "макросы". Например, можно ввести следующие макроопределения:

NEW_LINE \n | \n\r
NON_LINE [^\n]


Тогда описание C++ комментария будет выглядить не так страшно:

Comment // NON_LINE* NEW_LINE


По мне, это очень удобно. Понятно, что все свое место, описывать регулярками сложные языки сложно, лучше для таких целей использовать абстракции, адекватно выражающий отношение иерархии. Хотя, имеются прецеденты и обратного. Например, проверочный скрипт для инспекции C++ кода на соответствие Google style, написанный на Питоне, читает код построчно и проверяет каждую строку на соответствие регулярному выражению. При этом еще используется автомат, который содержит состояния типа "сейчас я внутри класса", "внутри функции" и т.п. Таким образом, используется два автомата: один для разбора конркетных строк, а другой -- метоавтомат, который позволяет держать контекст разбора. Этот подход вообще удобен для разбора протоколов. Например, у себя в компании мы написали специальный инструмент "Автопарсер", который реализует эту технологию. На ее основе написали HTTP и MIME парсеры за пару недель между чашками кофе.

В общем, основная мысль такая: для каждой задачи лучше использовать те инструменты, которые удобны для реализации этой задачи. Нет плохих инструментов, но есть их неадекватное применение.
Re[11]: PEG vs RegExp
От: z00n  
Дата: 01.07.10 08:00
Оценка: 21 (2)
Здравствуйте, VladD2, Вы писали:

VD>Это ты о peg sharp? Ну, дык это классический генератор парсеров. Он генерирует код который потом компилируется в исполнимый. Это обеспечивает более высокую скорость нежели если бы код итерпретировался бы. ХмлСериалайзер поступает так же.


Интерпретируемый код не всегда медленнее, например интепретируемый LPEG по скорости не устепает LEX/YACC.
Недавно проводились тесты, где интепретируемый LPEG (с моей подачи) слегка порвал Boost-Spirit:
http://fprog.ru/2010/issue5/dmitry-popov-optimizing-parser-combinators/

Haskell / Parsec 2                              | 3.5 МБ/с 
                                                | 
Haskell / attoparsec                            | 8.2 МБ/с
                                                | 
Классические парсер-комбинаторы на OCaml,       | 6.6 МБ/с
если включать время на преобразование из        | 
строки в список символов.                       | 
                                                | 
Они же, если считать только парсинг списка      | 18.9 МБ/с
                                                | 
Эти же комбинаторы были реализованы в варианте, | 8.3 МБ/с
где вместо списка использовалась пара           | 
строка-позиция. Такой вариант не требовал       | 
перевода из строки в список.                    | 
                                                | 
                                                | 
Парсер, сгенерированный ocamlyacc и ocamllex    | 12.9 МБ/с
                                                | 
Вариант на С++ с использованием библиотеки      | 18.1 МБ/с <--
парсер-комбинаторов Boost Spirit 2.             | 
                                                | 
Lua / LPEG (на языке Lua описывается            | 20.2 МБ/с <--
грамматика, а разбор по ней осуществляет        | 
модуль LPEG на Си).                             | 
                                                | 
Оптимизирующие парсер-комбинаторы на OCaml,     | 42.6 МБ/с
включая время на построение графа,              | 
его оптимизацию, построение таблицы и т. д.     | 
                                                | 
Наконец, вариант C# с System.Xml                | 46.0 МБ/с



При этом интерпретация грамматики 'с листа' очень полезная и приятная фича.
Re[12]: PEG vs RegExp
От: BulatZiganshin  
Дата: 01.07.10 08:23
Оценка:
Здравствуйте, z00n, Вы писали:

Z>Интерпретируемый код не всегда медленнее, например интепретируемый LPEG по скорости не устепает LEX/YACC.


я в таблице вижу только ocamlyacc и ocamllex
Люди, я люблю вас! Будьте бдительны!!!
Re[13]: PEG vs RegExp
От: z00n  
Дата: 01.07.10 09:00
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

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


Z>>Интерпретируемый код не всегда медленнее, например интепретируемый LPEG по скорости не устепает LEX/YACC.


BZ>я в таблице вижу только ocamlyacc и ocamllex


C LEX/YACC (и leg) сравнивали в другой статье: http://www.inf.puc-rio.br/~roberto/docs/ry08-4.pdf

Вот данные оттуда:


Size-of-input  LPEG  Lex/Yacc  leg

620k           33    23        40
2440k          130   110       147
3680k          187   173       227

Table 4: Time for Parsing a Simple Language
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 09:45
Оценка:
Здравствуйте, z00n, Вы писали:

Z>Это преувеличение:

Z>- проект OMETA для C#, Javascript,Python, Ruby, Scheme, CL etc
Z>- peg комбинаторный парсер входит в состав стандартной библиотеки Scala 2.8
Z>- для Java их несколько штук (Rats, Mouse etc)
Z>- для С, по крайней мере peg-leg: http://piumarta.com/software/peg/
Z>- для C++ — PEG Template Library: http://code.google.com/p/pegtl7/

Z>7Не всеми так же просто пользоваться, как LPEG или OMETA — но недостатка в парсерах определенно нет


Конечно же хорошо, что что-то есть. Но все что ты перечислил не является альтернативой для регулярных выражений. Все это не находится "в шаговой доступности". Из перечисленного только С++-ное решение, и возможно Scala-ное, являются библиотеками которые можно легко вызвать из своего проекта. OMeta# же идет по старому доброму пути внешних утилит генераторов парсеров. Причем все с теми же ошибками.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 09:52
Оценка:
Здравствуйте, z00n, Вы писали:

Z>Интерпретируемый код не всегда медленнее, например интепретируемый LPEG по скорости не устепает LEX/YACC.


Это кромешное заблуждение. LEX/YACC могут быть неудобны, ограничены и т.п. Но по скорсти (при приличной реализации) они просто не сравнимы ни с какими реализациями PEG. А уж об интерпретируемых и говорить не приходится.

Z>Недавно проводились тесты, где интепретируемый LPEG (с моей подачи) слегка порвал Boost-Spirit:

Z>http://fprog.ru/2010/issue5/dmitry-popov-optimizing-parser-combinators/

Приведенные результаты говорят сами за себя. Даже далеко не выдающийся System.Xml порвал все ваши парсеры. В тестах явная лажа. Или лаже ocamlyacc и ocamllex.
Z>
Z>Парсер, сгенерированный ocamlyacc и ocamllex    | 12.9 МБ/с
Z>Lua / LPEG (на языке Lua описывается            | 20.2 МБ/с <--
Z>Наконец, вариант C# с System.Xml                | 46.0 МБ/с
Z>


Z>При этом интерпретация грамматики 'с листа' очень полезная и приятная фича.


Соглашусь, что это приятный бонус. Но не считаю, что это уж так полезно. Обычно грамматика известна заранее, так что интерпретировать ее особо не надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 10:30
Оценка: 6 (1) +2
Здравствуйте, VladD2, Вы писали:

Одно другому не мешает, вообще-то.
при помощи EBNF хорошо описывать сложные конструкции, но вот целое число гораздо проще описать регэкспом "\d+".
Не говоря уже о том, что регулярно возникают задачи, в которых нужно выяснить какие-то свойства текста, без анализа его структуры, например:
кончается на а: "а$"
начинается на а: "^a"
начинается на ту же букву, что и кончается: "^(.).*\1$"

Плюс простая задача — предоставить пользователю фильтровать данные — сейчас ты его просишь ввести строчечку с регэкспом, и все — а как ты это без регэкспов будешь делать? Например, AdBlock режет рекламу, просто проверяя адрес на соответствие одному из списка регэкспов — ну и каким боком тут ПЕГ засунуть?

Более того, любимый всеми pattern matching — это тоже регэкспы.
Более того, то, само описание правила EBNF — это тоже регэксп.
В широком смысле, ессно.

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


Далее, если говорить конкретно о Perl, в котором сама мощная система регэкспов — там есть и рекурсивные регэспы тоже (встроенные), и еще много чего (в библиотеках).

Вот библиотеки для работы с регэкспами, просто оцени их количество:
http://cpan.uwinnipeg.ca/search?query=Regexp&amp;mode=dist

Конкретно модуль, обеспечивающий удобную работу с рекурсивными конструкциями — Regexp::Common:
http://cpan.uwinnipeg.ca/htdocs/Regexp-Common/Regexp/Common.html

А вот модуль для работы с грамматиками:
http://cpan.uwinnipeg.ca/htdocs/Regexp-Grammars/Regexp/Grammars.html

И у меня вот радостно крутится перловый скрипт, который фильтрует вывод gcc-шных ошибок, превращая километровые листинги в простые и понятные сообщения, и я не могу сказать, что скрипт какой-то сильно сложный или что он write-only (хотя бы потому, что я его поддерживаю уже года три, улучшая и допиливая).

Так что одно другому не мешает.
Но и не отменяет одно другого.
Оба хороши на своем месте.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 10:36
Оценка:
Здравствуйте, night beast, Вы писали:

NB>немного забавно, но в данном случае вы с владом (если отбросить его нелюбовь к плюсам) воюете на одной стороне


NB>собственно, цель поста -- донести пользу применения грамматик (и ПЕГ в частности) до общественности...


Ну, у меня сложилось впечатление, что цель поста (корневого, а не этого, в котором демонстрируется обратный парадокс Блаба) — сказать следующее: "Регэкспы — отстой, все на EBNF!"
Хотя регэкспы — совсем не отстой, и у них есть масса применений, в которых EBNF либо вообще невозможно использовать, либо это будет крайне неудобно.
С другой стороны, если такой провоцирующий лозунг — это просто способ привлечь внимание общественности к грамматикам, то я не против.
Общественность инертна, ее пинками шевелить надо, иначе не пошевелится.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: PEG vs RegExp
От: night beast СССР  
Дата: 01.07.10 10:50
Оценка: +1
NB>>немного забавно, но в данном случае вы с владом (если отбросить его нелюбовь к плюсам) воюете на одной стороне
NB>>собственно, цель поста -- донести пользу применения грамматик (и ПЕГ в частности) до общественности...

J>Ну, у меня сложилось впечатление, что цель поста (корневого, а не этого, в котором демонстрируется обратный парадокс Блаба) — сказать следующее: "Регэкспы — отстой, все на EBNF!"

J>Хотя регэкспы — совсем не отстой, и у них есть масса применений, в которых EBNF либо вообще невозможно использовать, либо это будет крайне неудобно.

я думаю это из-за отсутствия нормальных либ.
а так, посмотри на правила peg — почти один в один с регекспами.
Re[7]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 10:51
Оценка:
Здравствуйте, night beast, Вы писали:

NB>я думаю это из-за отсутствия нормальных либ.

NB>а так, посмотри на правила peg — почти один в один с регекспами.

Чем тебе Boost.Spirit не нормальаня либа? Или Boost.Xpressive?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: PEG vs RegExp
От: night beast СССР  
Дата: 01.07.10 10:59
Оценка: +1
Здравствуйте, jazzer, Вы писали:

NB>>я думаю это из-за отсутствия нормальных либ.

NB>>а так, посмотри на правила peg — почти один в один с регекспами.

J>Чем тебе Boost.Spirit не нормальаня либа? Или Boost.Xpressive?


нормальная библиотека, но правила C++ налагают некоторые ограничения на синтаксис.
к тому же, сравни с количеством библиотек для regexp (начиная с Xpressive)
Re[2]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.07.10 11:00
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>Одно другому не мешает, вообще-то.

J>при помощи EBNF хорошо описывать сложные конструкции, но вот целое число гораздо проще описать регэкспом "\d+".
J>Не говоря уже о том, что регулярно возникают задачи, в которых нужно выяснить какие-то свойства текста, без анализа его структуры, например:
J>кончается на а: "а$"
.StartsWith

J>начинается на а: "^a"

.EndsWith

J>начинается на ту же букву, что и кончается: "^(.).*\1$"

x[0] == x[x.Length-1]

Не нужно такое засилие regexp. Кроме того backreferences в "регулярных" выражениях делают их не совсем регулярными, значит теряется линейная сложность вычисления. РВ типа последнего могут очень сильно тормозить.


J>Более того, любимый всеми pattern matching — это тоже регэкспы.

J>Более того, то, само описание правила EBNF — это тоже регэксп.
J>В широком смысле, ессно.
Где такую траву берешь?

J>Далее, никто не мешает собирать регэкспы из простых регэкспов, ибо это просто строчки.

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


J>И тогда все будет читабельным.

Уверен? Для email видел regex?

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")
@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])



J>Далее, если говорить конкретно о Perl, в котором сама мощная система регэкспов — там есть и рекурсивные регэспы тоже (встроенные), и еще много чего (в библиотеках).

В перле они уже давно нерегулярные.
Re[9]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 11:02
Оценка: :)
Здравствуйте, night beast, Вы писали:

NB>нормальная библиотека, но правила C++ налагают некоторые ограничения на синтаксис.

NB>к тому же, сравни с количеством библиотек для regexp (начиная с Xpressive)
Просто большинство задач парсинга решается либо регэкспами, либо брутфорсом. Реальную ценность библиотеки парсинга с грамматикой ты почувствуешь, когда тебе нужно парсить нечто нетривиальное — согласись, такое нужно 1) очень редко; 2) если это нетрививальное — это что-то широко распространенное (XML, URI), то для него уже написан парсер, и тебе просто нужно взять его и юзать, не изобретая велосипед.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: PEG vs RegExp
От: night beast СССР  
Дата: 01.07.10 11:11
Оценка:
Здравствуйте, jazzer, Вы писали:

NB>>нормальная библиотека, но правила C++ налагают некоторые ограничения на синтаксис.

NB>>к тому же, сравни с количеством библиотек для regexp (начиная с Xpressive)
J>Просто большинство задач парсинга решается либо регэкспами, либо брутфорсом. Реальную ценность библиотеки парсинга с грамматикой ты почувствуешь, когда тебе нужно парсить нечто нетривиальное — согласись, такое нужно 1) очень редко; 2) если это нетрививальное — это что-то широко распространенное (XML, URI), то для него уже написан парсер, и тебе просто нужно взять его и юзать, не изобретая велосипед.

ну вот email что-то редкое?
Re[3]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 11:22
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>Не говоря уже о том, что регулярно возникают задачи, в которых нужно выяснить какие-то свойства текста, без анализа его структуры, например:

J>>кончается на а: "а$"
G>.StartsWith
ты это (и подобное) собираешься попросить юзера ввести? Типа "Введите Ваш критерий поиска (код на С#, не более 4к)"?

J>>Более того, любимый всеми pattern matching — это тоже регэкспы.

J>>Более того, то, само описание правила EBNF — это тоже регэксп.
J>>В широком смысле, ессно.
G>Где такую траву берешь?
У меня свои поставщики.
Чем регэксп "...(.+)" принципиально отличается от ПМ _:_:_:xs?

J>>Далее, никто не мешает собирать регэкспы из простых регэкспов, ибо это просто строчки.

G>Да ну? У меня есть regex, выделяющий последовательность символов, как мне сделать regex где эта последовательность не встречается в определенном месте?
Что имеется в виду под "определенным местом"?
На всякий случай: "(?!<regex>)"

J>>И тогда все будет читабельным.

G>Уверен?
Уверен.

G>Для email видел regex?

Видел, видел, не волнуйся ты так.
И где тут сборка из строчек?

J>>Далее, если говорить конкретно о Perl, в котором сама мощная система регэкспов — там есть и рекурсивные регэспы тоже (встроенные), и еще много чего (в библиотеках).

G>В перле они уже давно нерегулярные.
Как угодно.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 11:26
Оценка:
Здравствуйте, night beast, Вы писали:

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


NB>>>нормальная библиотека, но правила C++ налагают некоторые ограничения на синтаксис.

NB>>>к тому же, сравни с количеством библиотек для regexp (начиная с Xpressive)
J>>Просто большинство задач парсинга решается либо регэкспами, либо брутфорсом. Реальную ценность библиотеки парсинга с грамматикой ты почувствуешь, когда тебе нужно парсить нечто нетривиальное — согласись, такое нужно 1) очень редко; 2) если это нетрививальное — это что-то широко распространенное (XML, URI), то для него уже написан парсер, и тебе просто нужно взять его и юзать, не изобретая велосипед.

NB>ну вот email что-то редкое?

Нет, не редкое, именно поэтому для него уже есть парсеры, о чем я и говорю.
Например: http://cpan.uwinnipeg.ca/htdocs/Regexp-Common-Email-Address/Regexp/Common/Email/Address.html
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[13]: PEG vs RegExp
От: z00n  
Дата: 01.07.10 11:29
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Приведенные результаты говорят сами за себя. Даже далеко не выдающийся System.Xml порвал все ваши парсеры. В тестах явная лажа. Или лаже ocamlyacc и ocamllex.


Никто не мешает вам написать тесты для вашего PEG парсера и показать как вы рвете System.Xml — только я что-то сомневаюсь
И кстати, у LPEG/Lua примерно половина времени ушла на обработку результата, в не на парсинг.


Z>>Интерпретируемый код не всегда медленнее, например интепретируемый LPEG по скорости не уступает LEX/YACC.


VD>Это кромешное заблуждение. LEX/YACC могут быть неудобны, ограничены и т.п. Но по скорсти (при приличной реализации) они просто не сравнимы ни с какими реализациями PEG. А уж об интерпретируемых и говорить не приходится.


Это кромешное заблуждение утверждать что-то просто пососав палец.
Re[12]: PEG vs RegExp
От: night beast СССР  
Дата: 01.07.10 11:31
Оценка:
Здравствуйте, jazzer, Вы писали:

NB>>>>нормальная библиотека, но правила C++ налагают некоторые ограничения на синтаксис.

NB>>>>к тому же, сравни с количеством библиотек для regexp (начиная с Xpressive)
J>>>Просто большинство задач парсинга решается либо регэкспами, либо брутфорсом. Реальную ценность библиотеки парсинга с грамматикой ты почувствуешь, когда тебе нужно парсить нечто нетривиальное — согласись, такое нужно 1) очень редко; 2) если это нетрививальное — это что-то широко распространенное (XML, URI), то для него уже написан парсер, и тебе просто нужно взять его и юзать, не изобретая велосипед.

NB>>ну вот email что-то редкое?

J>Нет, не редкое, именно поэтому для него уже есть парсеры, о чем я и говорю.
J>Например: http://cpan.uwinnipeg.ca/htdocs/Regexp-Common-Email-Address/Regexp/Common/Email/Address.html

парсеры есть, но народ в основном, свое делает. и так дело обстоит не только с email.
причем не всегда на регекспах.
это можно понять, кому охота в проект левую либу тянуть.
Re[4]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.07.10 11:34
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>>>Не говоря уже о том, что регулярно возникают задачи, в которых нужно выяснить какие-то свойства текста, без анализа его структуры, например:

J>>>кончается на а: "а$"
G>>.StartsWith
J>ты это (и подобное) собираешься попросить юзера ввести? Типа "Введите Ваш критерий поиска (код на С#, не более 4к)"?
А ты заставляешь пользователей regex_ы вводить? Почему гугл с яндексом до этого не додумался?

J>>>Более того, любимый всеми pattern matching — это тоже регэкспы.

J>>>Более того, то, само описание правила EBNF — это тоже регэксп.
J>>>В широком смысле, ессно.
G>>Где такую траву берешь?
J>У меня свои поставщики.
J>Чем регэксп "...(.+)" принципиально отличается от ПМ _:_:_:xs?
Много чем.
Например regex работает для строк и то что ты написал гораздо проще записать в виде x.Substring(3, x.Length — 3)


J>>>Далее, никто не мешает собирать регэкспы из простых регэкспов, ибо это просто строчки.

G>>Да ну? У меня есть regex, выделяющий последовательность символов, как мне сделать regex где эта последовательность не встречается в определенном месте?
J>Что имеется в виду под "определенным местом"?
J>На всякий случай: "(?!<regex>)"
Такое кажись только perl и поддерживает, но там regex по мощности сравнимы с PEG, но имеют гораздо более хреновый синтаксис.

J>>>И тогда все будет читабельным.

G>>Уверен?
J>Уверен.
Ты наверное один такой.

J>>>Далее, если говорить конкретно о Perl, в котором сама мощная система регэкспов — там есть и рекурсивные регэспы тоже (встроенные), и еще много чего (в библиотеках).

G>>В перле они уже давно нерегулярные.
J>Как угодно.

Ты не понимаешь с чем споришь. Regex в перле — по функциональности тот же PEG, только унаследовали синтаксис регулярных выражений.
Парсеры, в отличие от регулярных выражений, умеют не только разбирать текст но и возвращать структуры, а не списки матчей.
Re[13]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 11:49
Оценка:
Здравствуйте, night beast, Вы писали:

J>>>>Просто большинство задач парсинга решается либо регэкспами, либо брутфорсом. Реальную ценность библиотеки парсинга с грамматикой ты почувствуешь, когда тебе нужно парсить нечто нетривиальное — согласись, такое нужно 1) очень редко; 2) если это нетрививальное — это что-то широко распространенное (XML, URI), то для него уже написан парсер, и тебе просто нужно взять его и юзать, не изобретая велосипед.


NB>>>ну вот email что-то редкое?

J>>Нет, не редкое, именно поэтому для него уже есть парсеры, о чем я и говорю.
J>>Например: http://cpan.uwinnipeg.ca/htdocs/Regexp-Common-Email-Address/Regexp/Common/Email/Address.html

NB>парсеры есть, но народ в основном, свое делает. и так дело обстоит не только с email.

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

И что? Такова природа е-мейла — нелегко его парсить.
Или ты считаешь, что его будет легко распарсить на EBNF?
Если люди не используют готовые библиотеки регэкспов — то кто их заставит использовать готовые библиотеки грамматик?
Эта проблема лежит не в плоскости "PEG vs RegExp".
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[14]: PEG vs RegExp
От: night beast СССР  
Дата: 01.07.10 11:59
Оценка:
Здравствуйте, jazzer, Вы писали:

NB>>парсеры есть, но народ в основном, свое делает. и так дело обстоит не только с email.

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

J>И что? Такова природа е-мейла — нелегко его парсить.

J>Или ты считаешь, что его будет легко распарсить на EBNF?

думаю что проще. по крайней мере понятней
http://boost-spirit.com/repository/applications/rfc821.cpp

J>Если люди не используют готовые библиотеки регэкспов — то кто их заставит использовать готовые библиотеки грамматик?

J>Эта проблема лежит не в плоскости "PEG vs RegExp".

да это я так, ворчу...
Re[5]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 12:09
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

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


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


J>>>>Не говоря уже о том, что регулярно возникают задачи, в которых нужно выяснить какие-то свойства текста, без анализа его структуры, например:

J>>>>кончается на а: "а$"
G>>>.StartsWith
J>>ты это (и подобное) собираешься попросить юзера ввести? Типа "Введите Ваш критерий поиска (код на С#, не более 4к)"?
G>А ты заставляешь пользователей regex_ы вводить?
Да не только я. Ворд с Экселем, например, тоже могут. И твой любимый редактор, если только это не Notepad, тоже это может.

G>Почему гугл с яндексом до этого не додумался?

Наверное, потому что их движки заточены немножко под другое, и они в принципе не способны искать по регэкспам?

J>>>>Более того, любимый всеми pattern matching — это тоже регэкспы.

J>>Чем регэксп "...(.+)" принципиально отличается от ПМ _:_:_:xs?
G>Много чем.
G>Например regex работает для строк
Неубедительно.
ПМ _:_:_:xs тоже работает для строк, можешь проверить, если есть Хаскель под рукой.
G>то что ты написал гораздо проще записать в виде x.Substring(3, x.Length — 3)
вот этот вот крокодил называется "гораздо проще"?
И в любом случае, это не ПМ.

J>>>>Далее, никто не мешает собирать регэкспы из простых регэкспов, ибо это просто строчки.

G>>>Да ну? У меня есть regex, выделяющий последовательность символов, как мне сделать regex где эта последовательность не встречается в определенном месте?
J>>Что имеется в виду под "определенным местом"?
J>>На всякий случай: "(?!<regex>)"
G>Такое кажись только perl и поддерживает, но там regex по мощности сравнимы с PEG, но имеют гораздо более хреновый синтаксис.
Да ну?
JavaScript тебя устроит? http://ru.wikipedia.org/wiki/ECMAScript#cite_note-specRegExp-64
Python? http://docs.python.org/library/re.html
С++? http://www.boost.org/libs/regex/doc/html/boost_regex/syntax/perl_syntax.html

J>>>>И тогда все будет читабельным.

G>>>Уверен?
J>>Уверен.
G>Ты наверное один такой.
Я вообще уникален во многих отношениях. Но не в этом. Ты не поверишь, но нормальные люди, которые, скажем, хотят сматчить нечто вроде "идентификатор,идентификатор:идентификатор", не будут писать
$re = "[a-zA-Z_][a-zA-Z0-9_]*,[a-zA-Z_][a-zA-Z0-9_]*:[a-zA-Z_][a-zA-Z0-9_]*";

а напишут
$id = "[a-zA-Z_][a-zA-Z0-9_]*";
$re = "$id,$id:$id";

Но ты, безусловно, волен считать, что я один такой.

J>>>>Далее, если говорить конкретно о Perl, в котором сама мощная система регэкспов — там есть и рекурсивные регэспы тоже (встроенные), и еще много чего (в библиотеках).

G>>>В перле они уже давно нерегулярные.
J>>Как угодно.
G>
G>Ты не понимаешь с чем споришь. Regex в перле — по функциональности тот же PEG, только унаследовали синтаксис регулярных выражений.
G>Парсеры, в отличие от регулярных выражений, умеют не только разбирать текст но и возвращать структуры, а не списки матчей.
ОК. В чем конкретно заключается нерегулярность перловых регэкспов?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[15]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 12:12
Оценка: 2 (1) :)
Здравствуйте, night beast, Вы писали:

J>>И что? Такова природа е-мейла — нелегко его парсить.

J>>Или ты считаешь, что его будет легко распарсить на EBNF?

NB>думаю что проще. по крайней мере понятней

ну так и кто мешает так же понятно записать регэксп? Это же просто строчка, которую можно собрать из более простых и коротких строчек, дав каждой осмысленное имя.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[16]: PEG vs RegExp
От: night beast СССР  
Дата: 01.07.10 12:30
Оценка:
Здравствуйте, jazzer, Вы писали:

J>>>И что? Такова природа е-мейла — нелегко его парсить.

J>>>Или ты считаешь, что его будет легко распарсить на EBNF?

NB>>думаю что проще. по крайней мере понятней

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

ну, убедил. регекспы справляются с парсингом email
Re[3]: PEG vs RegExp
От: z00n  
Дата: 01.07.10 12:30
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


J>>И тогда все будет читабельным.

G>Уверен? Для email видел regex?

G>
G>(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")
G>@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
G>


Кстати, вот как это выглядит на LPEG re:

p = re.compile[[
  address        <- <mailbox> / <group>
  group          <- <phrase> ":" [#mailbox] ";"
  mailbox        <- <addr_spec> / <phrase> <route_addr>
  route_addr     <- "<" <route>? <addr_spec> ">"
  route          <- (("@" <domain>) (","+ "@" <domain>)*) ":"
  addr_spec      <- <local_part> "@" <domain>
  local_part     <- <word> ("." <word>)*
  domain         <- <sub_domain> ("." <sub_domain>)*
  sub_domain     <- <domain_ref> / <domain_literal>
  domain_ref     <- <atom>
  domain_literal <- "[" ([^][] / "\" .)* "]"
  phrase         <- <word> (","+ <word>)*
  word           <- <atom> / <quoted_string>
  atom           <- [^] %c()<>@,;:\".[]+
  quoted_string  <- '"' ([^"\%nl] / "\" .)* '"'
]]
Re[6]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.07.10 12:35
Оценка:
Здравствуйте, jazzer, Вы писали:

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


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


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


J>>>>>Не говоря уже о том, что регулярно возникают задачи, в которых нужно выяснить какие-то свойства текста, без анализа его структуры, например:

J>>>>>кончается на а: "а$"
G>>>>.StartsWith
J>>>ты это (и подобное) собираешься попросить юзера ввести? Типа "Введите Ваш критерий поиска (код на С#, не более 4к)"?
G>>А ты заставляешь пользователей regex_ы вводить?
J>Да не только я. Ворд с Экселем, например, тоже могут.
Посмотрел Word и Excel 2010 не нашел такого функционала, в Wordpad тоже.

J>И твой любимый редактор, если только это не Notepad, тоже это может.

Visual Studio умеет, но это тул для программистов.

G>>Почему гугл с яндексом до этого не додумался?

J>Наверное, потому что их движки заточены немножко под другое, и они в принципе не способны искать по регэкспам?
Также они "в принципе" способны искать по любой грамматике.


J>>>>>Более того, любимый всеми pattern matching — это тоже регэкспы.

J>>>Чем регэксп "...(.+)" принципиально отличается от ПМ _:_:_:xs?
G>>Много чем.
G>>Например regex работает для строк
J>Неубедительно.
Что именно? Это факт вообще-то.

J>ПМ _:_:_:xs тоже работает для строк, можешь проверить, если есть Хаскель под рукой.

Он работает для любым списков, а не только для строк. Кроме того pattern matching — не только разбор списков.

G>>то что ты написал гораздо проще записать в виде x.Substring(3, x.Length — 3)

J>вот этот вот крокодил называется "гораздо проще"?
Именно, потому что это все выражение, которое достает подстроку с третьего символа, а РВ надо еще как-то запустить.



J>>>>>Далее, никто не мешает собирать регэкспы из простых регэкспов, ибо это просто строчки.

G>>>>Да ну? У меня есть regex, выделяющий последовательность символов, как мне сделать regex где эта последовательность не встречается в определенном месте?
J>>>Что имеется в виду под "определенным местом"?
J>>>На всякий случай: "(?!<regex>)"
G>>Такое кажись только perl и поддерживает, но там regex по мощности сравнимы с PEG, но имеют гораздо более хреновый синтаксис.
J>Да ну?
J>JavaScript тебя устроит? http://ru.wikipedia.org/wiki/ECMAScript#cite_note-specRegExp-64
J>Python? http://docs.python.org/library/re.html
И как будет выглядеть исключение некоторой подстроки в выражении?

J>С++? http://www.boost.org/libs/regex/doc/html/boost_regex/syntax/perl_syntax.html

Я же говорю perl

J>>>>>И тогда все будет читабельным.

G>>>>Уверен?
J>>>Уверен.
G>>Ты наверное один такой.
J>Я вообще уникален во многих отношениях. Но не в этом. Ты не поверишь, но нормальные люди, которые, скажем, хотят сматчить нечто вроде "идентификатор,идентификатор:идентификатор", не будут писать
J>
J>$re = "[a-zA-Z_][a-zA-Z0-9_]*,[a-zA-Z_][a-zA-Z0-9_]*:[a-zA-Z_][a-zA-Z0-9_]*";
J>

J>а напишут
J>
J>$id = "[a-zA-Z_][a-zA-Z0-9_]*";
J>$re = "$id,$id:$id";
J>

J>Но ты, безусловно, волен считать, что я один такой.
Да это я и так знаю. И с peg будет так же выглядеть.
А вот меня больше интересует исключение подстроки не на перле. В свое время такая задача мне мозг проела.


J>>>>>Далее, если говорить конкретно о Perl, в котором сама мощная система регэкспов — там есть и рекурсивные регэспы тоже (встроенные), и еще много чего (в библиотеках).

G>>>>В перле они уже давно нерегулярные.
J>>>Как угодно.
G>>
G>>Ты не понимаешь с чем споришь. Regex в перле — по функциональности тот же PEG, только унаследовали синтаксис регулярных выражений.
G>>Парсеры, в отличие от регулярных выражений, умеют не только разбирать текст но и возвращать структуры, а не списки матчей.
J>ОК. В чем конкретно заключается нерегулярность перловых регэкспов?
В том что для некоторых выражений не строится конечный автомат, а используется поиск с возвратом. (по сути тот же механизм что в прямой реализации peg).
Re[3]: PEG vs RegExp
От: mefrill Россия  
Дата: 01.07.10 12:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Да ну? У меня есть regex, выделяющий последовательность символов, как мне сделать regex где эта последовательность не встречается в определенном месте?


Есть теорема о том, что дополнение автоматного языка является автоматным языком. Иначе говоря, что для каждого конечного автомата A можно построить конечный автомат B, который допускает в точности дополнение языка автомата A. Используем теорему Клини и пишем программку, которая по данной регулярке строит конечный автомат, по нему автомат, допускающий дополнение, а уже по последнему -- искомое регулярное выражение. Это все можно сделать автоматически внутри программы. Можно не строить регулярное выражение и удовлетвориться автоматом, введя в языка описания операцию дополнения, так обычно и делается. Вот насчет построения дополнения для КС-языка я не уверен.
Re[4]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.07.10 13:00
Оценка:
Здравствуйте, mefrill, Вы писали:

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


G>>Да ну? У меня есть regex, выделяющий последовательность символов, как мне сделать regex где эта последовательность не встречается в определенном месте?


M>Есть теорема о том, что дополнение автоматного языка является автоматным языком. Иначе говоря, что для каждого конечного автомата A можно построить конечный автомат B, который допускает в точности дополнение языка автомата A. Используем теорему Клини и пишем программку, которая по данной регулярке строит конечный автомат, по нему автомат, допускающий дополнение, а уже по последнему -- искомое регулярное выражение. Это все можно сделать автоматически внутри программы. Можно не строить регулярное выражение и удовлетвориться автоматом, введя в языка описания операцию дополнения, так обычно и делается. Вот насчет построения дополнения для КС-языка я не уверен.



А я не говорил что это задача нерегулярна, просто во многих библиотеках regex такой возможности нет.
Re[5]: PEG vs RegExp
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 01.07.10 13:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Плюс практически уверен, что наш вариант намного более быстр, так как не использует делегатов, не создает АСТ и вообще не делает лишних телодвижений.


Ну, знаешь, сравнение парсера, создающего AST, и не делающего этого, это уже перебор.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
AVK Blog
Re[14]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 14:51
Оценка:
Здравствуйте, z00n, Вы писали:

Z>Никто не мешает вам написать тесты для вашего PEG парсера и показать как вы рвете System.Xml — только я что-то сомневаюсь


В этом нет необходимости. Правда про System.Xml я конечно некорректно высказался. System.Xml — это прстранство имен в котором в том числе есть и очень эффективный (но дико низкоуровневый) XmlTextReader. С ним по скорости трудно конкурировать, но тем не менее Яковский лексер (а XmlTextReader — это только лексер) должен работать с аналогичной скоростью.

Z>И кстати, у LPEG/Lua примерно половина времени ушла на обработку результата, в не на парсинг.


VD>>Это кромешное заблуждение. LEX/YACC могут быть неудобны, ограничены и т.п. Но по скорсти (при приличной реализации) они просто не сравнимы ни с какими реализациями PEG. А уж об интерпретируемых и говорить не приходится.


Z>Это кромешное заблуждение утверждать что-то просто пососав палец.


Да, да. Для тебя конечно 20 лет научных работ в этой области ничего не значат. Зато веришь любой фигне написанной в первом попавшемся ПДФ-е.

YACC строит ДКА. Это оначает скорость парсинга O(n). Для PEG-а построить ДКА невозможно. Остается или Пакрат с мемоизацией на которую тратится уйма вермени, или откаты и множественные переборы на которые время по любому уходит. А тут еще и интерпретация.

В общем искать ошибки в их тестах я не намерен. Но очевидно, что они там присутствуют. Чудес не бывает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 14:57
Оценка:
Здравствуйте, March_rabbit, Вы писали:

M_>ну и чем тогда весь тред? О том, что все бегом на немерле?


Ты в школу не ходил? Читать не умеешь? Или все повсюду используют PEG вместо регулярных выражений, а я один не знаю?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: PEG vs RegExp
От: mefrill Россия  
Дата: 01.07.10 14:58
Оценка: 1 (1) +1
Здравствуйте, VladD2, Вы писали:

VD>YACC строит ДКА.


YACC не строит ДКА, он строит т.н. кнутовский автомат для LR(1)-грамматики. Это автомат с магазином для хранения правых частей правил КС-грамматики. Поэтому, хотя он работает быстро, но все же не за линейное время. Согласен в том, что конечно парсеры с откатом он по любому делает и для данного языка оптимальный парсер строит. Тесты там действительно фигня полная.
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 14:59
Оценка:
Здравствуйте, alexeiz, Вы писали:

A>Regex'ы тоже в последнее время возможны рекурсивные и их тоже можно читать, по крайней мере в Perl 5.10:


Регексы по определению не могут быть рекурсивными.

A>А в Perl 6 они уже даже и выглядят элегантно.


Перл 6 основан на PEG. Плюс его вряд ли можно назвать господствующим языком. Да и нет его еще пока.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: PEG vs RegExp
От: Воронков Василий Россия  
Дата: 01.07.10 15:03
Оценка: 1 (1) +1
Здравствуйте, VladD2, Вы писали:

A>>Regex'ы тоже в последнее время возможны рекурсивные и их тоже можно читать, по крайней мере в Perl 5.10:

VD>Регексы по определению не могут быть рекурсивными.

По ходу перлисты с помощью, так сказать, "ловкости рук", подменили регекспы вполне полноценным КС-парсером, который упорно продолжает прикидывается регексами.
Re[15]: PEG vs RegExp
От: z00n  
Дата: 01.07.10 15:30
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Z>>Никто не мешает вам написать тесты для вашего PEG парсера и показать как вы рвете System.Xml — только я что-то сомневаюсь


VD>В этом нет необходимости. Правда про System.Xml я конечно некорректно высказался. System.Xml — это прстранство имен в котором в том числе есть и очень эффективный (но дико низкоуровневый) XmlTextReader. С ним по скорости трудно конкурировать, но тем не менее Яковский лексер (а XmlTextReader — это только лексер) должен работать с аналогичной скоростью.


Ничего он никому не должен. Легко, кстати, поставить эксперимент сравнив Lex и sed — sed ничуть не медленнее, хоть и 'интерпретатор'. Или вы, например, считаете, что Lex быстрее чем PCRE?


VD>Да, да. Для тебя конечно 20 лет научных работ в этой области ничего не значат. Зато веришь любой фигне написанной в первом попавшемся ПДФ-е.


Вы путаете источники — про LEX/YACC написано в опубликованной научной работе:
http://www.inf.puc-rio.br/~roberto/docs/ry08-4.pdf

А вот тут есть сравнения LPEG c PCRE и POSIX regex:
http://www.inf.puc-rio.br/~roberto/docs/peg.pdf

VD>YACC строит ДКА. Это оначает скорость парсинга O(n). Для PEG-а построить ДКА невозможно.


У вас тут огромный логический flaw.
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 15:43
Оценка:
Здравствуйте, jazzer, Вы писали:

VD>>Насколько я понимаю она использует похожий алгоритм рекурсивного спуска. Но думаю что без откатов.

J>И почему ты так думаешь?

Дык автоматы они вроде не строят. Пакрат не используют (это точно). Эрли и прочий GLR тоде не используется. Что остается?

J>Откаты там были с самой первой версии: кому нужен рекурсивный спуск без откатов


Если так, то это очень близко к реализации PEG-а без мемоизации.

VD>>Ну, а огромной проблемой этой библиотеки является средство реализации.


J>Прям так уже и "огромной"


Ага.

J>Под средством реализации имеется в виду сам язык С++?


Его шаблоны. Точнее метапрограммирование на шаблонах.

J> Тогда это какая-то странная претензия — библиотека же для С++


А раз для С++, то проблемы уже можно игнорировать?

J>Под "огромностью" проблемы обычно подразумевается практическая невозможность использования либо ее крайняя сложность. Ни того, ни другого я в Спирите не наблюдаю.


А так оно и получается. Практический пример грамматики калькулятора (созданной несколько лет назад) привел к тому, что на диске образовался каталог объемом под гиг. Сообщения об ошибках практически отсутствовали. Как в таких условиях создавать что-то мало-мальски большое?

VD>>Простенькие примеры выливаются в сотни мег занятого места на диске.


J>

J>можно пример "простенького примера" на "сотни мег"?

Можно скомпилируй на VC пример строчного калькулятора. Потом посмотри объем папки проекта.

J>вот простенький пример из документации:

J>http://www.boost.org/doc/libs/1_43_0/libs/spirit/doc/html/spirit/qi/tutorials/mini_xml___asts_.html, и где тут "сотни мег"?

На диске. Там генерируется море шаблононого кода который потом устраняется оптимизатором компилятора.

J>Если ты собираешься сказать что-то вроде "Это только в документации все хорошо, а в реальных проектах сотни мег", то я, как написавший достаточно парсеров на спирите, спешу тебя уверить, что это не так, все остается на том же простом уровне, и написание собственно парсера занимает копейки.


Написание то копейки, но вот на обработку уходит слишком много времени и ресурсов. Плюс сообщения об ошибках практически никакие.

Но согласен, что Спирит — это как раз то что нужно конечному прогрммисту. Это как раз та самая шаговая доступность, которая определяет широкое использование продукта.

J>Если ты вдруг о размерах бинарника — вот я только что скомпилировал пример калькулятора boost-1.38.0/libs/spirit/classic/example/fundamental/full_calc.cpp (причем компилировал стареньким gcc 3.4.6) — получился бинарник размером 33к. Где "сотни мег" — не пойму.


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

J>Да, еще стандартная претензия — время компиляции, так вот оно, время на компиляцию этого примера, компилятор тот же:

J>real 0m1.438s
J>user 0m1.070s
J>sys 0m0.124s

Полторы минуты на примитивную грамматику — это нормально?

Многие С++-ники считают дотнет медленным. Но на компиляцию того же примера с использованием макросов немерла (написанного полностью на немерле) уйдет 1-3 секунды.

Плюс можно сравнить сложность реализации Спирита и PEG-парсера (макроса). Уверен, что разница будет поразительной и не в пользу Спирита.

Ради интереса скачал буст и поглядел сколько занимают исходники Спирита. Оказалось 4 мега. Исходники PEG-парсера на немреле занимают 81 килобайт (среди которых 23 кб — это не используемый пока код построителя ДКА). Что называется почувствуйте разницу. А делают ведь они одно и то же.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: PEG vs RegExp
От: mefrill Россия  
Дата: 01.07.10 15:53
Оценка: 1 (1) +1
Здравствуйте, z00n, Вы писали:

Z>Ничего он никому не должен. Легко, кстати, поставить эксперимент сравнив Lex и sed — sed ничуть не медленнее, хоть и 'интерпретатор'. Или вы, например, считаете, что Lex быстрее чем PCRE?


Кстати, а как реализован sed? Я вот честно говоря не верю, что он строит детерминированный автомат для всех своих регулярок. Скроее всего, он строит автоматы для каждой из регулярок, а затем запускает их параллельно, эмулируя работу НКА. Lex сливает все автоматы в один детерминированный. Это будет работать по любому быстрее. Разница в скорости тем заметнее, чем больше выражений будет определено в sed. Наверное, есть еще разница в том, что Lex генерирует сишный код для автомата моделируя переходы через goto, а sed наверняка использует табличную реализацию фунции переходов автотмата.

Кроме того, а чем вообще провинился Lex? Почему он должен быть медленнее некоего PCRE? Lex писали умные люди, специалисты в своей области и написан он довольно грамотно. Считается, что реализация автомата через генерацию кода посредством goto быстрее любой табличной. Вообще, чтобы что-то сравнивать, надо понимать реализацию этих инструментов. В чем разница между реализациями Lex и PCRE?
Re[7]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 16:00
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>А ты заставляешь пользователей regex_ы вводить?

J>>Да не только я. Ворд с Экселем, например, тоже могут.
G>Посмотрел Word и Excel 2010 не нашел такого функционала, в Wordpad тоже.
Это у них называется wildcard:
http://word.mvps.org/faqs/general/usingwildcards.htm
Попробуй на досуге.

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

G>>>Почему гугл с яндексом до этого не додумался?

J>>Наверное, потому что их движки заточены немножко под другое, и они в принципе не способны искать по регэкспам?
G>Также они "в принципе" способны искать по любой грамматике.
Сорри, не понял.

J>>>>>>Более того, любимый всеми pattern matching — это тоже регэкспы.

J>>>>Чем регэксп "...(.+)" принципиально отличается от ПМ _:_:_:xs?
G>>>Много чем.
G>>>Например regex работает для строк
Это этот регэксп работает для строк, потому что ты его вызываешь для строк.
А вообще регэкспы работают с любой последовательностью чего угодно, потому что формулируются в терминах атомов (которые не обязательно символы в строке, а, например, могут быть белком в ДНК) и их комбинаций всякими скобками, плюсиками и прочим.
Все это строится на исчислении предикатов, через которые ты прогоняешь свою последовательность.
Какие это будет предикаты и каким смыслом ты их наделишь — зависит от твоей конкретной задачи.
Это могут быть символы в строке, или дома на улице, или белки в ДНК, или ноты в мелодии, или аргументы функции (ПМ).

J>>ПМ _:_:_:xs тоже работает для строк, можешь проверить, если есть Хаскель под рукой.

G>Он работает для любым списков, а не только для строк. Кроме того pattern matching — не только разбор списков.
А что еще? Я вот как-то все время вижу разбор списков, либо напрямую со списком, либо со списком аргументов.

G>>>то что ты написал гораздо проще записать в виде x.Substring(3, x.Length — 3)

J>>вот этот вот крокодил называется "гораздо проще"?
G>Именно, потому что это все выражение, которое достает подстроку с третьего символа, а РВ надо еще как-то запустить.
Да, всего-то надо написать import re или что там в твоем любимом языке надо для этого сделать.
А потом позвать функцию match/search/whatever.
Заметь, одну и ту же функцию, независимо от того, что ты ищешь.

J>>JavaScript тебя устроит? http://ru.wikipedia.org/wiki/ECMAScript#cite_note-specRegExp-64

J>>Python? http://docs.python.org/library/re.html
G>И как будет выглядеть исключение некоторой подстроки в выражении?
Я правильно понял, что ты ссылку и не подумал открыть даже?

(?!...)
Matches if ... doesn’t match next. This is a negative lookahead assertion. For example, Isaac (?!Asimov) will match 'Isaac ' only if it’s not followed by 'Asimov'.


J>>С++? http://www.boost.org/libs/regex/doc/html/boost_regex/syntax/perl_syntax.html

G>Я же говорю perl
Да, перловые регэкспы, которые поддерживают все, кому не лень.
Тебе шашечки или ехать?


G>Да это я и так знаю. И с peg будет так же выглядеть.

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

G>А вот меня больше интересует исключение подстроки не на перле. В свое время такая задача мне мозг проела.

Ну так надо было не мозг есть, а посмотреть по сторонам на библиотеки, которые поддерживают перловые регэкспы — их навалом, и во всех языках.
http://en.wikipedia.org/wiki/Regular_expression#Perl-derivative_regular_expressions

Due largely to its expressive power, many other utilities and programming languages have adopted syntax similar to Perl's — for example, Java, JavaScript, PCRE, Python, Ruby, Microsoft's .NET Framework, and the W3C's XML Schema all use regular expression syntax similar to Perl's. Some languages and tools such as Boost and PHP support multiple regular expression flavors. Perl-derivative regular expression implementations are not identical, and many implement only a subset of Perl's features. With Perl 5.10, this process has come full circle with Perl incorporating syntax extensions originally from Python, PCRE, the .NET Framework, and Java.


J>>ОК. В чем конкретно заключается нерегулярность перловых регэкспов?

G>В том что для некоторых выражений не строится конечный автомат, а используется поиск с возвратом. (по сути тот же механизм что в прямой реализации peg).
Поиск с возвратом придется строить даже для такого элементарного регэкспа: ".*?b+".
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[17]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 16:01
Оценка:
Здравствуйте, night beast, Вы писали:

NB>ну, убедил. регекспы справляются с парсингом email

Ну ты же меня именно про парсинг e-mail-а спрашивал
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[16]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 16:05
Оценка:
Здравствуйте, mefrill, Вы писали:

M>YACC не строит ДКА, он строит т.н. кнутовский автомат для LR(1)-грамматики. Это автомат с магазином для хранения правых частей правил КС-грамматики.


Да, гоню конечно немного. Но по сути все равно там время близкое к линейному. Я просто хотел сказать, что в отличии от рекурсивного спуска в LALR используется эффективное предсказание, что делает скорость близкой к оптимальной. Там другие проблемы. Построить работающую грамматику скажем для C# ну очень не просто (а скорее всего без приседаний вообще невозможно).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 16:16
Оценка:
Здравствуйте, VladD2, Вы писали:

J>>Под средством реализации имеется в виду сам язык С++?


VD>Его шаблоны. Точнее метапрограммирование на шаблонах.

Шаблоны неотделимы от С++. Т.е. все-таки С++.

J>> Тогда это какая-то странная претензия — библиотека же для С++

VD>А раз для С++, то проблемы уже можно игнорировать?

Проблемы у С++ есть, только это не повод называть любую проблему огромной.

J>>Под "огромностью" проблемы обычно подразумевается практическая невозможность использования либо ее крайняя сложность. Ни того, ни другого я в Спирите не наблюдаю.


VD>А так оно и получается. Практический пример грамматики калькулятора (созданной несколько лет назад) привел к тому, что на диске образовался каталог объемом под гиг. Сообщения об ошибках практически отсутствовали. Как в таких условиях создавать что-то мало-мальски большое?


Ты о чем вообще? Я же привел пример калькулятора на Спирите, он на странице умещается.

VD>>>Простенькие примеры выливаются в сотни мег занятого места на диске.


J>>

J>>можно пример "простенького примера" на "сотни мег"?

J>>вот простенький пример из документации:

J>>http://www.boost.org/doc/libs/1_43_0/libs/spirit/doc/html/spirit/qi/tutorials/mini_xml___asts_.html, и где тут "сотни мег"?

J>>Если ты собираешься сказать что-то вроде "Это только в документации все хорошо, а в реальных проектах сотни мег", то я, как написавший достаточно парсеров на спирите, спешу тебя уверить, что это не так, все остается на том же простом уровне, и написание собственно парсера занимает копейки.


VD>Написание то копейки, но вот на обработку уходит слишком много времени и ресурсов. Плюс сообщения об ошибках практически никакие.

Не увидел "слишком много времени и ресурсов". Мой пример показывает обратное.

VD>Но согласен, что Спирит — это как раз то что нужно конечному прогрммисту. Это как раз та самая шаговая доступность, которая определяет широкое использование продукта.


+1. И именно поэтому нет никакой "огромной" проблемы.

J>>Если ты вдруг о размерах бинарника — вот я только что скомпилировал пример калькулятора boost-1.38.0/libs/spirit/classic/example/fundamental/full_calc.cpp (причем компилировал стареньким gcc 3.4.6) — получился бинарник размером 33к. Где "сотни мег" — не пойму.


VD>Они рядом с твоим бинарником лежат. Ты измерий размеры каталога. Ну, и за одно померь время ушедшее на компиляцию.

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

J>>Да, еще стандартная претензия — время компиляции, так вот оно, время на компиляцию этого примера, компилятор тот же:

J>>real 0m1.438s
J>>user 0m1.070s
J>>sys 0m0.124s

VD>Полторы минуты на примитивную грамматику — это нормально?

Полторы секунды. Читай внимательнее.

VD>Многие С++-ники считают дотнет медленным. Но на компиляцию того же примера с использованием макросов немерла (написанного полностью на немерле) уйдет 1-3 секунды.

Ну если путать минуты и секунды, то, конечно, да.

VD>Плюс можно сравнить сложность реализации Спирита и PEG-парсера (макроса). Уверен, что разница будет поразительной и не в пользу Спирита.

Наверняка. Спирит пишется для С++, коего куча диалектов, и все надо поддерживать.

VD>Ради интереса скачал буст и поглядел сколько занимают исходники Спирита. Оказалось 4 мега. Исходники PEG-парсера на немреле занимают 81 килобайт (среди которых 23 кб — это не используемый пока код построителя ДКА). Что называется почувствуйте разницу. А делают ведь они одно и то же.

Очень может быть.
Ты комментарии убирал?
Твой пег-парсер умеет делать все, что умеет делать спирит?
Но, в принципе, я вполне верю, что код на Немерле будет меньше кода на С++, иначе нафиг тогда Немерле нужен, если он будет хуже С++.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: PEG vs RegExp
От: BulatZiganshin  
Дата: 01.07.10 17:17
Оценка:
Здравствуйте, jazzer, Вы писали:

VD>>Ради интереса скачал буст и поглядел сколько занимают исходники Спирита. Оказалось 4 мега. Исходники PEG-парсера на немреле занимают 81 килобайт


ну вот опять Влад берётся рассуждать о том, с чем не работал. afair, spirit включает в себя ни много ни мало целую систему lazy вычислений
Люди, я люблю вас! Будьте бдительны!!!
Re[16]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 17:18
Оценка: :)
Здравствуйте, z00n, Вы писали:

Z>Ничего он никому не должен. Легко, кстати, поставить эксперимент сравнив Lex и sed — sed ничуть не медленнее, хоть и 'интерпретатор'. Или вы, например, считаете, что Lex быстрее чем PCRE?


Я незнаю что такое "sed" и "PCRE" но я точно знаю что чудес не бывает. Если используемый алгоритм более эффективен и он в добавок использует скомпилированный код, а не интерпретацию, то он не может быть сравним по производительности с интерпретируемым и менее эффективным алгоритмом.

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

VD>>Да, да. Для тебя конечно 20 лет научных работ в этой области ничего не значат. Зато веришь любой фигне написанной в первом попавшемся ПДФ-е.


Z>Вы путаете источники — про LEX/YACC написано в опубликованной научной работе:

Z>http://www.inf.puc-rio.br/~roberto/docs/ry08-4.pdf

То что я путаю уже уточнил mefrill здесь
Автор: mefrill
Дата: 01.07.10
. Я с ним полностью согласен. Прочти его сообщение.

Z>А вот тут есть сравнения LPEG c PCRE и POSIX regex:

Z>http://www.inf.puc-rio.br/~roberto/docs/peg.pdf

Ага. Хороший документ. Спасибо за ссылку. Прочти в нем раздел "5. Performance" с самого начала. Там как раз обсуждаются все теоретические проблемы встающие при реализации парсеров для ПЕГ-а. Например, вот эта:

The time to match an ordered choice is the sum of the times for each option (as the first one may fail):
T (p1 / p2) = T (p1) + T (p2)

Так вот для предсказывающих парсеров это время всегда О(1).

VD>>YACC строит ДКА. Это оначает скорость парсинга O(n). Для PEG-а построить ДКА невозможно.


Z>У вас тут огромный логический flaw.


Да? Ну, просвети меня.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 17:26
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>Плюс практически уверен, что наш вариант намного более быстр, так как не использует делегатов, не создает АСТ и вообще не делает лишних телодвижений.


AVK>Ну, знаешь, сравнение парсера, создающего AST, и не делающего этого, это уже перебор.


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

Я вооще не понимаю зачем в генерированном коде использовать высокоуровневые конструкции.

ЗЫ

Кстати, что касается объема кода — это отличная демонстрация того как и где рулит функциональный подход .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 17:32
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Поиск с возвратом придется строить даже для такого элементарного регэкспа: ".*?b+".


Во как?

Про построение ДКА ты ничего не читал? Так вот уже лет 30 как есть такой алгорит. Он живенько устранит лишний вопросик и пероразует это выражение в эквивалетное ".*b+" которое. Это конечно образно говоря, так как преобразование конечно будет вестись на уровен конечных автоматво, а не регулярных выражений.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 17:34
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>ну вот опять Влад берётся рассуждать о том, с чем не работал.


Да ладно. Это твой хлеб .

BZ>afair, spirit включает в себя ни много ни мало целую систему lazy вычислений


Да хоть черта лысого. Важен исключительно результат. А результат весьма скромный при несопоставимых трудозатратах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: PEG vs RegExp
От: BulatZiganshin  
Дата: 01.07.10 17:40
Оценка:
Здравствуйте, VladD2, Вы писали:

BZ>>afair, spirit включает в себя ни много ни мало целую систему lazy вычислений


VD>Да хоть черта лысого. Важен исключительно результат. А результат весьма скромный при несопоставимых трудозатратах.


Влад, прсто прелестно читать как ты старательно подчёркиваешь 26 кб неиспользуемых в известной тебе библиотеке, и тут заявляешь что "важен исключительно результат" для неизвестной
Люди, я люблю вас! Будьте бдительны!!!
Re[9]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 17:41
Оценка:
Здравствуйте, VladD2, Вы писали:

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


J>>Поиск с возвратом придется строить даже для такого элементарного регэкспа: ".*?b+".


VD>Во как?


VD>Про построение ДКА ты ничего не читал? Так вот уже лет 30 как есть такой алгорит. Он живенько устранит лишний вопросик и пероразует это выражение в эквивалетное ".*b+" которое. Это конечно образно говоря, так как преобразование конечно будет вестись на уровен конечных автоматво, а не регулярных выражений.


А ты про регэкспы ничего не читал?
Это не "лишний вопросик", это — не жадная (non-greedy) версия квантификатора.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 17:49
Оценка:
Здравствуйте, jazzer, Вы писали:

VD>>Его шаблоны. Точнее метапрограммирование на шаблонах.

J>Шаблоны неотделимы от С++. Т.е. все-таки С++.

Тогда бери выше. Виноват комьюетер. На нем же все вычисляется.


J>>> Тогда это какая-то странная претензия — библиотека же для С++

VD>>А раз для С++, то проблемы уже можно игнорировать?

J>Проблемы у С++ есть, только это не повод называть любую проблему огромной.


Проблемы не у С++, а у конкретной реализаци конкретного инструмента.

VD>>А так оно и получается. Практический пример грамматики калькулятора (созданной несколько лет назад) привел к тому, что на диске образовался каталог объемом под гиг. Сообщения об ошибках практически отсутствовали. Как в таких условиях создавать что-то мало-мальски большое?


J>Ты о чем вообще? Я же привел пример калькулятора на Спирите, он на странице умещается.


Я о том, о чем пишу. Читай вдумчиво и внимательно.

VD>>Написание то копейки, но вот на обработку уходит слишком много времени и ресурсов. Плюс сообщения об ошибках практически никакие.

J>Не увидел "слишком много времени и ресурсов". Мой пример показывает обратное.

ОК. 1.5 минуты — это быстро?

А каков получается объем каталога с примером получается после компиляции этого примера?

Про сообщения об ошибках ты вообще решил промолчать. Так держать!

VD>>Но согласен, что Спирит — это как раз то что нужно конечному прогрммисту. Это как раз та самая шаговая доступность, которая определяет широкое использование продукта.


J>+1. И именно поэтому нет никакой "огромной" проблемы.


Не. Проблемы есть, но те кто очень не хотят их замечать их не замечают.

VD>>Они рядом с твоим бинарником лежат. Ты измерий размеры каталога. Ну, и за одно померь время ушедшее на компиляцию.

J>У меня нет никакого каталога, и ничего рядом не лежит. Был файл — собрался бинарник, все просто. Да, я на юниксе сижу, если что, не в Студии.

Да хоть на Линуксе или Линусе. Твой компилятор С++ промежуточные файлы при компиляции не создает? Если создает, то куда он их помещает? Вот сотри их, скомпилируй пример и измерь каталог в который они были помещены.


J>>>Да, еще стандартная претензия — время компиляции, так вот оно, время на компиляцию этого примера, компилятор тот же:

J>>>real 0m1.438s
J>>>user 0m1.070s
J>>>sys 0m0.124s

VD>>Полторы минуты на примитивную грамматику — это нормально?

J>Полторы секунды. Читай внимательнее.

Ой что-то я тебе совсем не верю. Мой опыт использования спирита был совсем другим. Пример парсера выражений компилировался довольно долго. Видимо 1.5 секунды у тебя с прекомпилированным изаголовками (т.е. 1.5 секунды линкер отрабатывает).

VD>>Плюс можно сравнить сложность реализации Спирита и PEG-парсера (макроса). Уверен, что разница будет поразительной и не в пользу Спирита.

J>Наверняка. Спирит пишется для С++, коего куча диалектов, и все надо поддерживать.

А! Понял! Раелизация там 100 килобайт, а 3.9 метра — это пляски с бубном вокруг диалектов (коих быть не должно, так как есть стандарт). Очень смешно!

VD>>Ради интереса скачал буст и поглядел сколько занимают исходники Спирита. Оказалось 4 мега. Исходники PEG-парсера на немреле занимают 81 килобайт (среди которых 23 кб — это не используемый пока код построителя ДКА). Что называется почувствуйте разницу. А делают ведь они одно и то же.

J>Очень может быть.
J>Ты комментарии убирал?

Нет. Каюсь. Так там 4 метра комментариев?

J>Твой пег-парсер умеет делать все, что умеет делать спирит?


Ну, крестиком не вышивает и на гармошке играть не умеет. А так парсит, да.

J>Но, в принципе, я вполне верю, что код на Немерле будет меньше кода на С++, иначе нафиг тогда Немерле нужен, если он будет хуже С++.


Да я тоже в этом не сомневался. Но 0.05 метра супротив 4 метров — это все таки перебор. Не находишь? Это же почти в 100 раз!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 17:53
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>Влад, прсто прелестно читать как ты старательно подчёркиваешь 26 кб неиспользуемых в известной тебе библиотеке, и тут заявляешь что "важен исключительно результат" для неизвестной


26 кб — это что?

Исходники Спирита занимают 4 мб. Так... для информации. Весь код компилятора немерла составляете ~2 мб. А ленивость предоставляется в библиотечных фунциях занимающих несколько байт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 17:59
Оценка:
Здравствуйте, jazzer, Вы писали:

J>А ты про регэкспы ничего не читал?

J>Это не "лишний вопросик", это — не жадная (non-greedy) версия квантификатора.

А... Сори.

Ну, в любом случае для любого регулярного выражения можно построить ДКА. Более того ДКА как раз не жадные. Так что это будет даже проще.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 01.07.10 18:13
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Его шаблоны. Точнее метапрограммирование на шаблонах.

J>>Шаблоны неотделимы от С++. Т.е. все-таки С++.
VD>Тогда бери выше. Виноват комьюетер. На нем же все вычисляется.
Не, это ты у нас в обвинителях ходишь, ты и бери. Мне и так хорошо. И главное, это все имеет прямое отношение к обсуждаемой теме.

VD>Проблемы не у С++, а у конкретной реализаци конкретного инструмента.

Хорошо, объясни, как надо было конкретный инструмент (библиотека для парсинга на С++) реализовывать?

VD>>>А так оно и получается. Практический пример грамматики калькулятора (созданной несколько лет назад) привел к тому, что на диске образовался каталог объемом под гиг. Сообщения об ошибках практически отсутствовали. Как в таких условиях создавать что-то мало-мальски большое?


J>>Ты о чем вообще? Я же привел пример калькулятора на Спирите, он на странице умещается.


VD>Я о том, о чем пишу. Читай вдумчиво и внимательно.

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

VD>ОК. 1.5 минуты — это быстро?

1.5 секунды. Из них реальной компиляции — 1.070s. Читай вдумчиво и внимательно.

VD>А каков получается объем каталога с примером получается после компиляции этого примера?


VD>Про сообщения об ошибках ты вообще решил промолчать. Так держать!

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

VD>Не. Проблемы есть, но те кто очень не хотят их замечать их не замечают.

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

VD>>>Они рядом с твоим бинарником лежат. Ты измерий размеры каталога. Ну, и за одно померь время ушедшее на компиляцию.

J>>У меня нет никакого каталога, и ничего рядом не лежит. Был файл — собрался бинарник, все просто. Да, я на юниксе сижу, если что, не в Студии.

VD>Да хоть на Линуксе или Линусе. Твой компилятор С++ промежуточные файлы при компиляции не создает? Если создает, то куда он их помещает? Вот сотри их, скомпилируй пример и измерь каталог в который они были помещены.

Не создает, не помещает. Просто бинарник. Читай вдумчиво и внимательно.


J>>>>Да, еще стандартная претензия — время компиляции, так вот оно, время на компиляцию этого примера, компилятор тот же:

J>>>>real 0m1.438s
J>>>>user 0m1.070s
J>>>>sys 0m0.124s

VD>>>Полторы минуты на примитивную грамматику — это нормально?

J>>Полторы секунды. Читай внимательнее.

VD>Ой что-то я тебе совсем не верю. Мой опыт использования спирита был совсем другим. Пример парсера выражений компилировался довольно долго. Видимо 1.5 секунды у тебя с прекомпилированным изаголовками (т.е. 1.5 секунды линкер отрабатывает).

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

VD>>>Плюс можно сравнить сложность реализации Спирита и PEG-парсера (макроса). Уверен, что разница будет поразительной и не в пользу Спирита.

J>>Наверняка. Спирит пишется для С++, коего куча диалектов, и все надо поддерживать.

VD>А! Понял! Раелизация там 100 килобайт, а 3.9 метра — это пляски с бубном вокруг диалектов (коих быть не должно, так как есть стандарт). Очень смешно!

VD>Нет. Каюсь. Так там 4 метра комментариев?
VD>Ну, крестиком не вышивает и на гармошке играть не умеет. А так парсит, да.

Понятно. Не читал, но осуждаю. Бывает. Обратный парадокс Блаба в действии.

J>>Но, в принципе, я вполне верю, что код на Немерле будет меньше кода на С++, иначе нафиг тогда Немерле нужен, если он будет хуже С++.

VD>Да я тоже в этом не сомневался. Но 0.05 метра супротив 4 метров — это все таки перебор. Не находишь? Это же почти в 100 раз!
Ну вот когда твой парсер начнет крестиком вышивать и на гармошке играть, тогда и поговорим.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: PEG vs RegExp
От: Воронков Василий Россия  
Дата: 01.07.10 18:18
Оценка:
Здравствуйте, jazzer, Вы писали:

VD>>Да хоть на Линуксе или Линусе. Твой компилятор С++ промежуточные файлы при компиляции не создает? Если создает, то куда он их помещает? Вот сотри их, скомпилируй пример и измерь каталог в который они были помещены.

J>Не создает, не помещает. Просто бинарник. Читай вдумчиво и внимательно.

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

VD>>>>Полторы минуты на примитивную грамматику — это нормально?

J>>>Полторы секунды. Читай внимательнее.

А на какой машине происходит компиляция?

VD>>Да я тоже в этом не сомневался. Но 0.05 метра супротив 4 метров — это все таки перебор. Не находишь? Это же почти в 100 раз!

J>Ну вот когда твой парсер начнет крестиком вышивать и на гармошке играть, тогда и поговорим.

Я спиритом не пользовался, но ваше обсуждение меня, честно говоря, заинтриговала. А какие еще задачи, кроме парсинга, можно решать с помощью спирита?
Re: PEG vs RegExp
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 01.07.10 18:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD> Более того, первые ласточки его использования уже есть – создана библиотека LPEG, которая позиционируется как замена регулярных выражений для языка Lua. Однако надеяться на победоносное шествие PEG по господствующим языкам и фреймворкам (Java, .NET, C++) не приходится.


ЩИТО? Да полно ведь реализаций уже:
http://en.wikipedia.org/wiki/Comparison_of_parser_generators#Parsing_Expression_Grammars

VD> Но выше крыши не прыгнишь. Плюс алгоритм там самый что ни на есть дубовый (пербор с откатами) и тут уже ничего не оптимизируешь.


Элементарно PEG оптимизируется:
http://fprog.ru/2010/issue5/dmitry-popov-optimizing-parser-combinators/
И быстрые автоматы из комбинаторов строить можно.
А, вижу ссылку уже дали.
Re[8]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.07.10 18:37
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Не, это ты у нас в обвинителях ходишь, ты и бери. Мне и так хорошо. И главное, это все имеет прямое отношение к обсуждаемой теме.


В каких обвинителях? Я просто заметил, что средство реализации (метапрограммировние на шаблонах) не очень хорошо подходит для решения задачи.

J>Хорошо, объясни, как надо было конкретный инструмент (библиотека для парсинга на С++) реализовывать?


На С++ был только один нормальный выход. Написать библиотеку которая бы делала все чтонужно принимая грамматики в виде строки. Ну, или классический генератор кода + компиляция. Это тоже можно было бы завернуть в библиотечную функцию (вон в дотнете для сериализации в ХМЛ так делают и ничего).

VD>>Про сообщения об ошибках ты вообще решил промолчать. Так держать!

J>У меня нет проблем с сообщениями об ошибках. Ты ж ничего конкретного не спросил, только общие слова в воздух. Что конкретно тебе интересует?

Хорошо тебе. А вот другие могут опечататься и не понимать что от них хочет компилятор. Наверно снова VC виноват.

J>Не создает, не помещает. Просто бинарник. Читай вдумчиво и внимательно.


Ну, прям VC отстой видимо. Все беды из-за него. А другие компилятора в мговения ока три тонны шаблонов перемалывают.

VD>>Ой что-то я тебе совсем не верю. Мой опыт использования спирита был совсем другим. Пример парсера выражений компилировался довольно долго. Видимо 1.5 секунды у тебя с прекомпилированным изаголовками (т.е. 1.5 секунды линкер отрабатывает).

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

Как говорил О.Бэндэр — "С таким здоровьем и на свободе!". Ну, рад за тебя если все так замечательно... у тебя.

VD>>Ну, крестиком не вышивает и на гармошке играть не умеет. А так парсит, да.


J>Понятно. Не читал, но осуждаю. Бывает. Обратный парадокс Блаба в действии.


Что не читал? Ты спросил делает ли он то же. Я ответил.


J>>>Но, в принципе, я вполне верю, что код на Немерле будет меньше кода на С++, иначе нафиг тогда Немерле нужен, если он будет хуже С++.

VD>>Да я тоже в этом не сомневался. Но 0.05 метра супротив 4 метров — это все таки перебор. Не находишь? Это же почти в 100 раз!
J>Ну вот когда твой парсер начнет крестиком вышивать и на гармошке играть, тогда и поговорим.

А зачем ему вышивать то? Он же не кот Матросскин? Построитель парсер должен строить парсеры. Не больше, не меньше. На входе граммактика и список обработчиков, на выходе готовый парсер. Это он делает. Вот пресетов для парсинга числе и т.п. нет. Это да. Но они и не нужны когда грамматика описывается не на птичьем языке, а нормально.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: PEG vs RegExp
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 01.07.10 18:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В этом нет необходимости. Правда про System.Xml я конечно некорректно высказался. System.Xml — это прстранство имен в котором в том числе есть и очень эффективный (но дико низкоуровневый) XmlTextReader. С ним по скорости трудно конкурировать, но тем не менее Яковский лексер (а XmlTextReader — это только лексер) должен работать с аналогичной скоростью.


Если это лексер, как же он XML с его рекурсивной структурой разбирает?

VD>YACC строит ДКА. Это оначает скорость парсинга O(n). Для PEG-а построить ДКА невозможно.


Там в обоих случаях автомат с магазином (стеком) строится. Простой ДКА (без стека) и LR грамматику не возьмет.
Re[16]: PEG vs RegExp
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 01.07.10 18:51
Оценка:
Здравствуйте, mefrill, Вы писали:

M>Тесты там действительно фигня полная.


Там есть ссылка на исходники. Буду рад услышать, где в тестах ошибка.
Re[3]: PEG vs RegExp
От: Jack128  
Дата: 01.07.10 19:02
Оценка: +1
Здравствуйте, March_rabbit, Вы писали:

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


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


Да я все понимаю. Но ся пересилить не могу.
Re[8]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.07.10 19:46
Оценка:
Здравствуйте, jazzer, Вы писали:

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


G>>>>А ты заставляешь пользователей regex_ы вводить?

J>>>Да не только я. Ворд с Экселем, например, тоже могут.
G>>Посмотрел Word и Excel 2010 не нашел такого функционала, в Wordpad тоже.
J>Это у них называется wildcard:
J>http://word.mvps.org/faqs/general/usingwildcards.htm
J>Попробуй на досуге.
Так ты сравнил **й с пальцем. Одно дело регулярные выражения в перле, совсем другое wildcards в редакторе. Мощность у них разная. Я даже не уверен что wildcards покрывает все регулярные языки.

J>С другой стороны, я так и не услышал твоего варианта, как ты предоставишь пользователю поиск типа все слова, начинающиеся на а, и тому подобные варианты. Равно как и блокировку рекламы, как в AdBlock.

Я бы лучше сделал DSL для предикатов. Хотя для тех кто настраивает adblock регэкспы могут оказаться проще.

J>>>>>>>Более того, любимый всеми pattern matching — это тоже регэкспы.

J>>>>>Чем регэксп "...(.+)" принципиально отличается от ПМ _:_:_:xs?
G>>>>Много чем.
G>>>>Например regex работает для строк
J>Это этот регэксп работает для строк, потому что ты его вызываешь для строк.
J>А вообще регэкспы работают с любой последовательностью чего угодно, потому что формулируются в терминах атомов (которые не обязательно символы в строке, а, например, могут быть белком в ДНК) и их комбинаций всякими скобками, плюсиками и прочим.
Круто, и что? Есть библиотеки которые это реализуют? Они массово используются?

J>Все это строится на исчислении предикатов, через которые ты прогоняешь свою последовательность.

J>Какие это будет предикаты и каким смыслом ты их наделишь — зависит от твоей конкретной задачи.
J>Это могут быть символы в строке, или дома на улице, или белки в ДНК, или ноты в мелодии, или аргументы функции (ПМ).
Про аргументы функции — чушь.

J>>>ПМ _:_:_:xs тоже работает для строк, можешь проверить, если есть Хаскель под рукой.

G>>Он работает для любым списков, а не только для строк. Кроме того pattern matching — не только разбор списков.
J>А что еще? Я вот как-то все время вижу разбор списков, либо напрямую со списком, либо со списком аргументов.
Значит плохо смотришь. Ты бы хоть в справке посмотрел какие паттерны в хаскеле есть.

G>>>>то что ты написал гораздо проще записать в виде x.Substring(3, x.Length — 3)

J>>>вот этот вот крокодил называется "гораздо проще"?
G>>Именно, потому что это все выражение, которое достает подстроку с третьего символа, а РВ надо еще как-то запустить.
J>Да, всего-то надо написать import re или что там в твоем любимом языке надо для этого сделать.
J>А потом позвать функцию match/search/whatever.
В C# для того же самого надо написать гораздо больше кода, чем один вызов substring. Тоже самое верно почти для любого другого языка.

J>Заметь, одну и ту же функцию, независимо от того, что ты ищешь.

А это как раз недостаток, ибо смысл действий скрыт внутри regexp, а тот же Substring очень хорошо описывает результат.


J>>>JavaScript тебя устроит? http://ru.wikipedia.org/wiki/ECMAScript#cite_note-specRegExp-64

J>>>Python? http://docs.python.org/library/re.html
G>>И как будет выглядеть исключение некоторой подстроки в выражении?
J>Я правильно понял, что ты ссылку и не подумал открыть даже?
Я открыл, но ботать здоровые спецификации мне лениво.

J>

J>(?!...)
J> Matches if ... doesn’t match next. This is a negative lookahead assertion. For example, Isaac (?!Asimov) will match 'Isaac ' only if it’s not followed by 'Asimov'.


J>>>С++? http://www.boost.org/libs/regex/doc/html/boost_regex/syntax/perl_syntax.html

G>>Я же говорю perl
J>Да, перловые регэкспы, которые поддерживают все, кому не лень.
.NET не поддерживает, в java тоже не перловые regex.

J>Тебе шашечки или ехать?

Именно ехать, поэтому я не использую regex на каждом шагу.

G>>Да это я и так знаю. И с peg будет так же выглядеть.

J>И в чем тогда преимущество ПЕГа? В этой конкретной задаче, я имею в виду.
В такой маленькой — ни в чем, а вот пример с email уже привели.

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

J>А с грамматикой ты что будешь делать?
Тоже самое.
Хотя в моих проектах как-то 99% регулярок статичны.


J>>>ОК. В чем конкретно заключается нерегулярность перловых регэкспов?

G>>В том что для некоторых выражений не строится конечный автомат, а используется поиск с возвратом. (по сути тот же механизм что в прямой реализации peg).
J>Поиск с возвратом придется строить даже для такого элементарного регэкспа: ".*?b+".
Я честно говоря не совсем понял что это за выражение. Но если у тебя появляется поиск с возвратами, то ты уже используешь инструмент, сравнимый по мощности с PEG, но с гораздо более убогим синтаксисом.
Re[10]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 01.07.10 20:06
Оценка:
Здравствуйте, jazzer, Вы писали:

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


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


J>>>Поиск с возвратом придется строить даже для такого элементарного регэкспа: ".*?b+".


VD>>Во как?


VD>>Про построение ДКА ты ничего не читал? Так вот уже лет 30 как есть такой алгорит. Он живенько устранит лишний вопросик и пероразует это выражение в эквивалетное ".*b+" которое. Это конечно образно говоря, так как преобразование конечно будет вестись на уровен конечных автоматво, а не регулярных выражений.


J>А ты про регэкспы ничего не читал?

J>Это не "лишний вопросик", это — не жадная (non-greedy) версия квантификатора.

Вот теперь понял что делает этот regex.
1)Если требуется только матчить строку, то нету разницы жадный или нежадный квантификатор. Прямое построение ДКА по регэкспу дает именно нежадный алгоритм.
2)Если требуется извлечь подстроки, соответствующие паттернам, то используется не поиск с возвратом, а выставление начальных и конечных позиций матча (дополнительные действия в ДКА), кроме того изменяется сам ДКА для обеспечения жадности.

Это касаемо стандартных regex, для расширений, вроде backreferences, нужны откаты.
Re[11]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 02.07.10 00:11
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это касаемо стандартных regex, для расширений, вроде backreferences, нужны откаты.


Ну, вообще-то, backreferences даже в самых базовых POSIX Basic Regular Expressions есть, не говоря уже о перле.
Куда уж стандартнее.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 02.07.10 01:36
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>Это у них называется wildcard:

J>>http://word.mvps.org/faqs/general/usingwildcards.htm
J>>Попробуй на досуге.
G>Так ты сравнил **й с пальцем. Одно дело регулярные выражения в перле, совсем другое wildcards в редакторе. Мощность у них разная. Я даже не уверен что wildcards покрывает все регулярные языки.

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

J>>С другой стороны, я так и не услышал твоего варианта, как ты предоставишь пользователю поиск типа все слова, начинающиеся на а, и тому подобные варианты. Равно как и блокировку рекламы, как в AdBlock.

G>Я бы лучше сделал DSL для предикатов. Хотя для тех кто настраивает adblock регэкспы могут оказаться проще.
Ну и как бы на твоем DSL выглядел бы вот такой запрос: "сначала буква а, потом что угодно, потом любая цифра, кроме нуля, только чтоб перед ней не было неприличного слова из четырех букв, потом опциональный пробел, потом слово из трех букв, но не неприличное". Напоминаю для сравнения — регэксп записывается в одну строку, так что достаточно предоставить юзеру поле ввода, и все.

ЗЫ регэкспы — это тоже DSL, причем широкоизвестный и общепринятый, изобретенный как раз для этих целей. Так что, раз уж ты пришел к идее DSL — может, лучше использовать стандартный?

J>>>>>>>>Более того, любимый всеми pattern matching — это тоже регэкспы.

J>>>>>>Чем регэксп "...(.+)" принципиально отличается от ПМ _:_:_:xs?
J>>А вообще регэкспы работают с любой последовательностью чего угодно, потому что формулируются в терминах атомов (которые не обязательно символы в строке, а, например, могут быть белком в ДНК) и их комбинаций всякими скобками, плюсиками и прочим.
G>Круто, и что? Есть библиотеки которые это реализуют? Они массово используются?
Ну, генетики этим реально пользуются, насколько я знаю.

J>>Все это строится на исчислении предикатов, через которые ты прогоняешь свою последовательность.

J>>Какие это будет предикаты и каким смыслом ты их наделишь — зависит от твоей конкретной задачи.
J>>Это могут быть символы в строке, или дома на улице, или белки в ДНК, или ноты в мелодии, или аргументы функции (ПМ).
G>Про аргументы функции — чушь.
Т.е. остальное принято? Ну хоть что-то.

J>>>>ПМ _:_:_:xs тоже работает для строк, можешь проверить, если есть Хаскель под рукой.

G>>>Он работает для любым списков, а не только для строк. Кроме того pattern matching — не только разбор списков.
J>>А что еще? Я вот как-то все время вижу разбор списков, либо напрямую со списком, либо со списком аргументов.
G>Значит плохо смотришь. Ты бы хоть в справке посмотрел какие паттерны в хаскеле есть.
Ну и какие же, кроме предикатов и их комбинаций?

G>>>>>то что ты написал гораздо проще записать в виде x.Substring(3, x.Length — 3)

J>>Да, всего-то надо написать import re или что там в твоем любимом языке надо для этого сделать.
J>>А потом позвать функцию match/search/whatever.
G>В C# для того же самого надо написать гораздо больше кода, чем один вызов substring. Тоже самое верно почти для любого другого языка.
да? странно. Можно пример для C#?
Потому что в других языка "гораздо больше кода" навскидку не наблюдается.
Вот Питон, например:
>>> import re
>>> re.match( "...(.*)", "123456789" ).group(1)
['456789']

Вот С++, Boost.Regex ( с Boost.Xpressive будет cregex_compiler().compile("...(.*)") ):
cmatch result;
if (regex_match( "123456789", result, regex( "...(.*)" )))
  std::cout << result[1] << std::endl;



J>>Заметь, одну и ту же функцию, независимо от того, что ты ищешь.

G>А это как раз недостаток, ибо смысл действий скрыт внутри regexp, а тот же Substring очень хорошо описывает результат.
regex_match тоже замечательно описывает результат.
Ну, как ты понимаешь, одно и то же может быть как недостатком, так и достоинством.
В случае, когда к тебе алгоритм поиска прилетает из конфига, это превращается в достоинство.

G>.NET не поддерживает, в java тоже не перловые regex.

Let me Google this for you:
Java: http://java.sun.com/javase/7/docs/api/java/util/regex/Pattern.html Ищи заголовок "Special constructs (named-capturing and non-capturing)"
.NET: http://msdn.microsoft.com/en-us/library/az24scfc.aspx#grouping_constructs

J>>Тебе шашечки или ехать?

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

G>>>Да это я и так знаю. И с peg будет так же выглядеть.

J>>И в чем тогда преимущество ПЕГа? В этой конкретной задаче, я имею в виду.
G>В такой маленькой — ни в чем, а вот пример с email уже привели.
Опять двадцать пять. По каким религиозным соображениям нельзя собрать длинную строчку регэкспа из простых и понятных коротких строчек?

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

J>>А с грамматикой ты что будешь делать?
G>Тоже самое.
То же самое что? Что пользователь будет вводить и в каком виде?


З.Ы. Еще раз — я не нападаю на грамматики, я сам их широко использую в виде Спирита.
Но для простых вещей регэкспы заруливают грамматики именно с точки зрения простоты, компактности и того, что это — просто строчка. Т.е. если мне нужно поискать что-нть в файлах (grep), или настроить в программе логику в зависимости от того, как выглядит некая строчка (чтоб алгоритм выбора лежал в конфиге и не нужно было перекомпилировать на каждый чих; это была реальная задача на работе, кстати, решение заняло 2 строчки, как ты уже видел выше) — тут регэкспы рулят.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 02.07.10 01:57
Оценка: 3 (1) +1
Здравствуйте, VladD2, Вы писали:

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


J>>Не, это ты у нас в обвинителях ходишь, ты и бери. Мне и так хорошо. И главное, это все имеет прямое отношение к обсуждаемой теме.

VD>В каких обвинителях? Я просто заметил, что средство реализации (метапрограммировние на шаблонах) не очень хорошо подходит для решения задачи.
Это в контексте Немерле. А в контексте С++ — замечательно подходит.

J>>Хорошо, объясни, как надо было конкретный инструмент (библиотека для парсинга на С++) реализовывать?


VD>На С++ был только один нормальный выход. Написать библиотеку которая бы делала все чтонужно принимая грамматики в виде строки.

Как ты в таком случае обеспечишь semantic actions?
VD>Ну, или классический генератор кода + компиляция. Это тоже можно было бы завернуть в библиотечную функцию (вон в дотнете для сериализации в ХМЛ так делают и ничего).
дотнет вообще весь динамический и рефлективный, там и классы можно прям в рантайме генерить. Но мы говорим о С++.
Насчет классического генератора кода — это очень неудобно, поэтому, как ты и сам отметил в корневом сообщении, этим никто не пользуется.
Плюс генератор код никак не взаимодействует с окружением, ибо он за пределами. А грамматика на Спирите — это все тот же С++ (у меня в программе, например, часть грамматики генерилась шаблонами, а еще часть, динамическая — прямо в рантайме).

J>>У меня нет проблем с сообщениями об ошибках. Ты ж ничего конкретного не спросил, только общие слова в воздух. Что конкретно тебе интересует?

VD>Хорошо тебе. А вот другие могут опечататься и не понимать что от них хочет компилятор. Наверно снова VC виноват.
Да, мне хорошо, я и не спорю. Я обычно понимаю, что от меня хочет компилятор. И, как я уже говорил рядом, у меня есть специальный скрипт (прикинь, на перле и регэкспах!), который помогает компилятору объяснять, чего ему надо.

J>>Не создает, не помещает. Просто бинарник. Читай вдумчиво и внимательно.

VD>Ну, прям VC отстой видимо. Все беды из-за него.
Еще раз — у меня никаких бед нет. Как ты сам сказал выше, мне хорошо.

VD>А другие компилятора в мговения ока три тонны шаблонов перемалывают.

Наверное. Я тебе время компиляции на стареньком gcc 3.4.6 продемонстрировал. Думаю, последний gcc 4.5 будет еще быстрее, учитывая внимание разработчиков именно к скорости перемалывания шаблонов.

VD>Как говорил О.Бэндэр — "С таким здоровьем и на свободе!". Ну, рад за тебя если все так замечательно... у тебя.

Да, спасибо, я тоже за себя рад.

VD>>>Ну, крестиком не вышивает и на гармошке играть не умеет. А так парсит, да.

J>>Понятно. Не читал, но осуждаю. Бывает. Обратный парадокс Блаба в действии.
VD>Что не читал? Ты спросил делает ли он то же. Я ответил.
Ага, замечательный ответ был, про крестик и гармошку. Сразу видно, что человек детально ознакомился с возможностями Спирита и может аргументированно сопоставить его возможности с возможностями своего парсера на Немерле. Надо взять на вооружение.

VD>А зачем ему вышивать то? Он же не кот Матросскин? Построитель парсер должен строить парсеры. Не больше, не меньше. На входе граммактика и список обработчиков, на выходе готовый парсер. Это он делает. Вот пресетов для парсинга числе и т.п. нет. Это да. Но они и не нужны когда грамматика описывается не на птичьем языке, а нормально.

Ага. Вот опишешь 50 раз парсинг вещественного числа по IEEE — и задумаешься, что неплохо бы, наверное, для стандартных примитивов все же готовые парсеры иметь.

ЗЫ Давай языковую часть "С++ vs. Nemerle" оставим прямо здесь и продолжим разговор только в контексте тобой же заявленной темы?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 02.07.10 02:34
Оценка: 6 (1)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Было бы неплохо, если б ты действительно посмотрел, каков объем генерируемых исходников для твоего примера. Не флейма ради, просто интересно.


скомпилировал, полученный объектник весит 102к. При этом половина объектника — это символы для линкера, если их убрать (командой strip) — 54к.

VD>>>>>Полторы минуты на примитивную грамматику — это нормально?

J>>>>Полторы секунды. Читай внимательнее.

ВВ>А на какой машине происходит компиляция?

ксеон E5540, компилятор — древний gcc 3.4.6. Все файлы на NFS, кстати.

ВВ>Я спиритом не пользовался, но ваше обсуждение меня, честно говоря, заинтриговала. А какие еще задачи, кроме парсинга, можно решать с помощью спирита?


Ну, в общем, тут достаточно вот эту страничку прочитать:
http://www.boost.org/libs/spirit/doc/html/spirit/introduction.html
Как видишь, там 4 библиотеки сразу — построитель парсеров (новая и старая, для совместимости), построитель лексеров и построитель генераторов.
Плюс Phoenix, движок для semantic actions (это типа Boost.Lambda, только заточен под Спирит). В языках со встроенными лямбдами он, скорее всего, не будет нужен вообще либо это будет просто тонкая обертка. В принципе, обычные функторы, собранные при помощи Boost.Bind и Boost.Lambda, и сейчас поддерживаются: http://www.boost.org/libs/spirit/doc/html/spirit/qi/tutorials/semantic_actions.html
Есть поддержка таблиц символов.
Есть поддержка разнообразных стилей обращения с пробелами.
Все парсеры атрибутированы, т.е. результат сработавшего парсера представляет собой некую структуру данных в памяти, например, для квантора повторения "repeat[a]" это будет vector<A>, для опционального "-a" — optional<A>, для альтернативы "a | b" — variant<A, B>, и т.д. Ну и в обратную сторону, когда строится генератор.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[16]: PEG vs RegExp
От: night beast СССР  
Дата: 02.07.10 03:30
Оценка: 7 (1)
Здравствуйте, z00n, Вы писали:


VD>>В этом нет необходимости. Правда про System.Xml я конечно некорректно высказался. System.Xml — это прстранство имен в котором в том числе есть и очень эффективный (но дико низкоуровневый) XmlTextReader. С ним по скорости трудно конкурировать, но тем не менее Яковский лексер (а XmlTextReader — это только лексер) должен работать с аналогичной скоростью.


Z>Ничего он никому не должен. Легко, кстати, поставить эксперимент сравнив Lex и sed — sed ничуть не медленнее, хоть и 'интерпретатор'. Или вы, например, считаете, что Lex быстрее чем PCRE?


вот здесь интересное сравнение реализаций регекспов
http://swtch.com/~rsc/regexp/regexp1.html
Re[12]: PEG vs RegExp
От: night beast СССР  
Дата: 02.07.10 03:34
Оценка:
Здравствуйте, jazzer, Вы писали:

G>>Это касаемо стандартных regex, для расширений, вроде backreferences, нужны откаты.


J>Ну, вообще-то, backreferences даже в самых базовых POSIX Basic Regular Expressions есть, не говоря уже о перле.

J>Куда уж стандартнее.

глянь сравнение по скорости:
http://swtch.com/~rsc/regexp/regexp1.html
к сожалению, за все приходится платить.
Re[13]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 02.07.10 03:57
Оценка:
Здравствуйте, night beast, Вы писали:

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


G>>>Это касаемо стандартных regex, для расширений, вроде backreferences, нужны откаты.


J>>Ну, вообще-то, backreferences даже в самых базовых POSIX Basic Regular Expressions есть, не говоря уже о перле.

J>>Куда уж стандартнее.

NB>глянь сравнение по скорости:

NB>http://swtch.com/~rsc/regexp/regexp1.html
NB>к сожалению, за все приходится платить.

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

Но мне лично скорости перловых регэкспов вполне хватает — такие вырожденные регэкспы, как в статье, в реальной жизни не бывают, а на реальных задачах меня скорость более чем устраивает.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[14]: PEG vs RegExp
От: night beast СССР  
Дата: 02.07.10 04:26
Оценка:
Здравствуйте, jazzer, Вы писали:

J>>>Ну, вообще-то, backreferences даже в самых базовых POSIX Basic Regular Expressions есть, не говоря уже о перле.

J>>>Куда уж стандартнее.

NB>>глянь сравнение по скорости:

NB>>http://swtch.com/~rsc/regexp/regexp1.html
NB>>к сожалению, за все приходится платить.

J>Да, я тебе за этот линк уже в другом сообщении оценку поставил

J>Речь не о том, что придется платить — с этим и не спорит никто, вроде.
J>Речь шла о стандартности некоторых конструкций.
J>Которые есть и в упомянутом в статье awk.

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


Re[12]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.07.10 05:02
Оценка:
Здравствуйте, jazzer, Вы писали:

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


G>>Это касаемо стандартных regex, для расширений, вроде backreferences, нужны откаты.


J>Ну, вообще-то, backreferences даже в самых базовых POSIX Basic Regular Expressions есть, не говоря уже о перле.

J>Куда уж стандартнее.

То что есть в спецификации W3C и поддерживается большинством библиотек.
Re[10]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.07.10 05:42
Оценка:
Здравствуйте, jazzer, Вы писали:

J>>>С другой стороны, я так и не услышал твоего варианта, как ты предоставишь пользователю поиск типа все слова, начинающиеся на а, и тому подобные варианты. Равно как и блокировку рекламы, как в AdBlock.

G>>Я бы лучше сделал DSL для предикатов. Хотя для тех кто настраивает adblock регэкспы могут оказаться проще.
J>Ну и как бы на твоем DSL выглядел бы вот такой запрос: "сначала буква а, потом что угодно, потом любая цифра, кроме нуля, только чтоб перед ней не было неприличного слова из четырех букв, потом опциональный пробел, потом слово из трех букв, но не неприличное". Напоминаю для сравнения — регэксп записывается в одну строку, так что достаточно предоставить юзеру поле ввода, и все.
J>ЗЫ регэкспы — это тоже DSL, причем широкоизвестный и общепринятый, изобретенный как раз для этих целей. Так что, раз уж ты пришел к идее DSL — может, лучше использовать стандартный?
Для записи матчинга по всему урлу regexp неудобен. ИМХО удобнее записывать предикаты для частей.

J>>>>>>>>>Более того, любимый всеми pattern matching — это тоже регэкспы.

J>>>>>>>Чем регэксп "...(.+)" принципиально отличается от ПМ _:_:_:xs?
J>>>А вообще регэкспы работают с любой последовательностью чего угодно, потому что формулируются в терминах атомов (которые не обязательно символы в строке, а, например, могут быть белком в ДНК) и их комбинаций всякими скобками, плюсиками и прочим.
G>>Круто, и что? Есть библиотеки которые это реализуют? Они массово используются?
J>Ну, генетики этим реально пользуются, насколько я знаю.
Ну я видел пример округления чисел на regex (на форуме пробегал), но не думаю что так стоит делать.

J>>>Все это строится на исчислении предикатов, через которые ты прогоняешь свою последовательность.

J>>>Какие это будет предикаты и каким смыслом ты их наделишь — зависит от твоей конкретной задачи.
J>>>Это могут быть символы в строке, или дома на улице, или белки в ДНК, или ноты в мелодии, или аргументы функции (ПМ).
G>>Про аргументы функции — чушь.
J>Т.е. остальное принято? Ну хоть что-то.
Остальное теория, 99,999% регэкспов пишутся для текста. При этом в половине случаев или есть готовое решение для тех же задач (типа StartsWith) или надо применять более мощные парсеры (парсинг HTML, арфиметических выражений итп).

J>>>>>ПМ _:_:_:xs тоже работает для строк, можешь проверить, если есть Хаскель под рукой.

G>>>>Он работает для любым списков, а не только для строк. Кроме того pattern matching — не только разбор списков.
J>>>А что еще? Я вот как-то все время вижу разбор списков, либо напрямую со списком, либо со списком аргументов.
G>>Значит плохо смотришь. Ты бы хоть в справке посмотрел какие паттерны в хаскеле есть.
J>Ну и какие же, кроме предикатов и их комбинаций?
http://habrahabr.ru/blogs/Haskell/50600/

G>>>>>>то что ты написал гораздо проще записать в виде

J>>>Да, всего-то надо написать import re или что там в твоем любимом языке надо для этого сделать.
J>>>А потом позвать функцию match/search/whatever.
G>>В C# для того же самого надо написать гораздо больше кода, чем один вызов substring. Тоже самое верно почти для любого другого языка.
J>да? странно. Можно пример для C#?

var m = Regex.Match(x,"...(.*)");
if(m.Success)
{
  return x.Value;
}
else
{
  ...
}

//Сравни с
x.Substring(3, x.Length - 3)


J>Потому что в других языка "гораздо больше кода" навскидку не наблюдается.

J>Вот Питон, например:
J>
>>>> import re
>>>> re.match( "...(.*)", "123456789" ).group(1)
J>['456789']
J>

J>Вот С++, Boost.Regex ( с Boost.Xpressive будет cregex_compiler().compile("...(.*)") ):
J>
J>cmatch result;
J>if (regex_match( "123456789", result, regex( "...(.*)" )))
J>  std::cout << result[1] << std::endl;
J>

Ты обработку ошибок не учел.

J>>>Заметь, одну и ту же функцию, независимо от того, что ты ищешь.

G>>А это как раз недостаток, ибо смысл действий скрыт внутри regexp, а тот же Substring очень хорошо описывает результат.
J>regex_match тоже замечательно описывает результат.
J>Ну, как ты понимаешь, одно и то же может быть как недостатком, так и достоинством.
J>В случае, когда к тебе алгоритм поиска прилетает из конфига, это превращается в достоинство.
Еще раз: в 99% случаев паттерны фиксированы при компиляции. Даже если не фиксированы, то более мощная и читаемая грамматика гораздо лучше "птичьего языка" регэкспов.

G>>.NET не поддерживает, в java тоже не перловые regex.

J>Let me Google this for you:
J>Java: http://java.sun.com/javase/7/docs/api/java/util/regex/Pattern.html Ищи заголовок "Special constructs (named-capturing and non-capturing)"
J>.NET: http://msdn.microsoft.com/en-us/library/az24scfc.aspx#grouping_constructs
Я уже и забыл про них. Использовал один раз, нарвался на тормоза из-за lookahead и забил на эти конструкции.

J>>>Тебе шашечки или ехать?

G>>Именно ехать, поэтому я не использую regex на каждом шагу.
J>Потому что, как мы все только что видели, ты просто не знаешь, что предоставляет твоя платформа.
Это уже 4 уровень — знаю и не использую.


G>>>>Да это я и так знаю. И с peg будет так же выглядеть.

J>>>И в чем тогда преимущество ПЕГа? В этой конкретной задаче, я имею в виду.
G>>В такой маленькой — ни в чем, а вот пример с email уже привели.
J>Опять двадцать пять. По каким религиозным соображениям нельзя собрать длинную строчку регэкспа из простых и понятных коротких строчек?
Ок, а что с нерегулярной грамматикой делать будешь?

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

J>>>А с грамматикой ты что будешь делать?
G>>Тоже самое.
J>То же самое что? Что пользователь будет вводить и в каком виде?
Для peg регулярное подмножество записывается почти также, как и в регэкспах, поэтому тоже самое будет.


J>З.Ы. Еще раз — я не нападаю на грамматики, я сам их широко использую в виде Спирита.

J>Но для простых вещей регэкспы заруливают грамматики именно с точки зрения простоты, компактности и того, что это — просто строчка. Т.е. если мне нужно поискать что-нть в файлах (grep), или настроить в программе логику в зависимости от того, как выглядит некая строчка (чтоб алгоритм выбора лежал в конфиге и не нужно было перекомпилировать на каждый чих; это была реальная задача на работе, кстати, решение заняло 2 строчки, как ты уже видел выше) — тут регэкспы рулят.
У тебя сразу много заблуждений собрано в одном месте.
1)Грамматика PEG такая же строчка, особенно если описываешь регулярный язык
2)Современные регэкспы обладают большей мощностью, чем регулярные грамматики и используют тот же самый поиск с возвратом для матча. При этом все это нагружается хреновым синтаксисом и регэкспы становятся write-only. Поэтому никаких преимуществ сложных регэкспов перед PEG нету. Для простых смотри п1.
3)99% паттернов в программах статичны, поэтому преимущества "просто строчки" становятся на самом деле недостатками из-за плохой читаемости "просто строчек" и необходимости компиляции. В nemerle предлагается compile-time генерация парсера.

Ты представляешь себе парсер КС языка как некоторую тяжелую хрень, с лексером, компиляцией в автомат с нечитаемым кодом итп. Peg предлагает гораздо более простую альтернативу.
Re[17]: PEG vs RegExp
От: mefrill Россия  
Дата: 02.07.10 05:57
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Там есть ссылка на исходники. Буду рад услышать, где в тестах ошибка.


Не хочу тратить время и искать очевидные ошибки в тестировании. Очевидно, что рекурсивный парсер с откатами не может быть быстрее, чему LR(1)-автомат. Может они подобрали тексты так, может криво грамматику для Yacc реализовали, не знаю. Какая разница? В любом случае, провести тестирование -- половина дела. Надо еще объяснить, почему тесты дали такие результаты. Как они объясняют тот факт, что заведомо более медленный алгоритм работает быстрее заведомо более быстрого? Может быть, криво реализован Yacc? Может быть тесты проводились на специфических языках? Как такое произошло?
Re[15]: PEG vs RegExp
От: fddima  
Дата: 02.07.10 06:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В этом нет необходимости. Правда про System.Xml я конечно некорректно высказался. System.Xml — это прстранство имен в котором в том числе есть и очень эффективный (но дико низкоуровневый) XmlTextReader. С ним по скорости трудно конкурировать, но тем не менее Яковский лексер (а XmlTextReader — это только лексер) должен работать с аналогичной скоростью.

XmlTextReader это всё же таки парсер и лексера там как такового нет вообще.
Дичайших оптимизаций в XmlTextReader тоже нет — абсолютно прозрачная работа с входными данными как они есть, без всяких лишних абстракций. В случае с XML это хорошо работает.
Re[11]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 02.07.10 06:57
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>Ну и как бы на твоем DSL выглядел бы вот такой запрос: "сначала буква а, потом что угодно, потом любая цифра, кроме нуля, только чтоб перед ней не было неприличного слова из четырех букв, потом опциональный пробел, потом слово из трех букв, но не неприличное". Напоминаю для сравнения — регэксп записывается в одну строку, так что достаточно предоставить юзеру поле ввода, и все.

J>>ЗЫ регэкспы — это тоже DSL, причем широкоизвестный и общепринятый, изобретенный как раз для этих целей. Так что, раз уж ты пришел к идее DSL — может, лучше использовать стандартный?
G>Для записи матчинга по всему урлу regexp неудобен. ИМХО удобнее записывать предикаты для частей.
Я пример увижу? А то пока только какие-то сферические предикаты в вакууме, которые все сделают. Где псевдокод на чудо-ДСЛе, который удобнее, чем регэкспы?

J>>Ну, генетики этим реально пользуются, насколько я знаю.

G>Ну я видел пример округления чисел на regex (на форуме пробегал), но не думаю что так стоит делать.
А в Киеве дядька. При чем тут округление чисел?

G>Остальное теория, 99,999% регэкспов пишутся для текста. При этом в половине случаев или есть готовое решение для тех же задач (типа StartsWith) или надо применять более мощные парсеры (парсинг HTML, арфиметических выражений итп).

Ты прям мои слова повторяешь, которые я night_beast'у говорил.

J>>>>>>ПМ _:_:_:xs тоже работает для строк, можешь проверить, если есть Хаскель под рукой.

G>>>>>Он работает для любым списков, а не только для строк. Кроме того pattern matching — не только разбор списков.
J>>>>А что еще? Я вот как-то все время вижу разбор списков, либо напрямую со списком, либо со списком аргументов.
G>>>Значит плохо смотришь. Ты бы хоть в справке посмотрел какие паттерны в хаскеле есть.
J>>Ну и какие же, кроме предикатов и их комбинаций?
G>http://habrahabr.ru/blogs/Haskell/50600/

G>
G>var m = Regex.Match(x,"...(.*)");
G>if(m.Success)
G>{
G>  return x.Value;
G>}
G>else
G>{
G>  ...
G>}

G>//Сравни с
G>x.Substring(3, x.Length - 3)
G>

Слушай, ну это не смешно даже.
Это называется "гораздо больше кода"?
Или ты еще и пустые строчки считаешь?

J>>Вот Питон, например:

J>>
>>>>> import re
>>>>> re.match( "...(.*)", "123456789" ).group(1)
J>>['456789']
J>>

J>>Вот С++, Boost.Regex ( с Boost.Xpressive будет cregex_compiler().compile("...(.*)") ):
J>>
J>>cmatch result;
J>>if (regex_match( "123456789", result, regex( "...(.*)" )))
J>>  std::cout << result[1] << std::endl;
J>>


G>Ты обработку ошибок не учел.

А у тебя где обработка ошибок?
Там иф стоит, видел? А Питон просто бросит исключение, но и в нем можно иф заюзать.
А вот ты длину строки не проверил — на шарпе/яве оно, может, и ничего, а на С/С++ будет пробежка по памяти с фейерверками.
А с проверкой строки — будет тот же самый иф.
И чем "if ( x.Length > 3 ) return x.Substring(3, x.Length — 3)" лучше, чем "if ( match( ... ) ) return group(1)", я не вижу.
Зато вижу, чем хуже — неуниверсальностью, троекратным повторением числа 3 (что легко приводит к ошибкам, если понадобится заменить, скажем, на 5), необходимостью перекомпиляции, ели понадобится что-то другое, невозможностью задать алгоритм сравнения извне.

G>Еще раз: в 99% случаев паттерны фиксированы при компиляции. Даже если не фиксированы, то более мощная и читаемая грамматика гораздо лучше "птичьего языка" регэкспов.

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

G>>>.NET не поддерживает, в java тоже не перловые regex.

J>>Let me Google this for you:
J>>Java: http://java.sun.com/javase/7/docs/api/java/util/regex/Pattern.html Ищи заголовок "Special constructs (named-capturing and non-capturing)"
J>>.NET: http://msdn.microsoft.com/en-us/library/az24scfc.aspx#grouping_constructs
G>Я уже и забыл про них. Использовал один раз, нарвался на тормоза из-за lookahead и забил на эти конструкции.
После всех твоих предыдущих утверждений про проеденную голову и отсутствие поддержки чуть ли не везде, кроме перла, если честно, верится с трудом, что ты действительно использовал lookahead.
Ну да ладно, проехали.

J>>Опять двадцать пять. По каким религиозным соображениям нельзя собрать длинную строчку регэкспа из простых и понятных коротких строчек?

G>Ок, а что с нерегулярной грамматикой делать будешь?
парсер заюзаю, вестимо.
А ты думал, что я буду везде регэкспы лепить, что ли?

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

J>>>>А с грамматикой ты что будешь делать?
G>>>Тоже самое.
J>>То же самое что? Что пользователь будет вводить и в каком виде?
G>Для peg регулярное подмножество записывается почти также, как и в регэкспах, поэтому тоже самое будет.
пример, плиз. Задача поставлена в начале прошлого сообщения.
А то какие-то абстрактные рассуждения то о ПЕГе, то вообще о своем собственном DSL, а примера нет как нет.

J>>З.Ы. Еще раз — я не нападаю на грамматики, я сам их широко использую в виде Спирита.

J>>Но для простых вещей регэкспы заруливают грамматики именно с точки зрения простоты, компактности и того, что это — просто строчка. Т.е. если мне нужно поискать что-нть в файлах (grep), или настроить в программе логику в зависимости от того, как выглядит некая строчка (чтоб алгоритм выбора лежал в конфиге и не нужно было перекомпилировать на каждый чих; это была реальная задача на работе, кстати, решение заняло 2 строчки, как ты уже видел выше) — тут регэкспы рулят.
G>У тебя сразу много заблуждений собрано в одном месте.
G>1)Грамматика PEG такая же строчка, особенно если описываешь регулярный язык
пример, плиз. Сравним "такие же" строчки.

G>2)Современные регэкспы обладают большей мощностью, чем регулярные грамматики и используют тот же самый поиск с возвратом для матча. При этом все это нагружается хреновым синтаксисом и регэкспы становятся write-only. Поэтому никаких преимуществ сложных регэкспов перед PEG нету. Для простых смотри п1.

G>3)99% паттернов в программах статичны, поэтому преимущества "просто строчки" становятся на самом деле недостатками из-за плохой читаемости "просто строчек" и необходимости компиляции. В nemerle предлагается compile-time генерация парсера.
99% _твоих_ паттернов статичны — так правильнее.

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

Сеанс телепатии не удался. Я не предлагаю использовать регэкспы для парсинга языков с развитой грамматикой — для этого нужно использовать грамматики.
Я лишь все эти два дня говорю лишь о том, что всему свое место, есть ниша и для грамматик, и для регэкспов, и для готовых plug-n-play парсеров типа msxml. А вы меня тут на пару с Владом пытаетесь убедить, что для регэкспов ниши нету, потому что пег рулит "ваще везде" и может заменить регэкспы опять же "ваще везде". Причем без примеров, которые бы могли меня раз и навсегда убедить отказаться от регэкспов и стереть с диска grep.

ЗЫ. На всякий случай напоминаю задачу:
"сначала буква а, потом что угодно, потом любая цифра, кроме нуля, только чтоб перед ней не было неприличного слова из четырех букв, потом опциональный пробел, потом слово из трех букв, но не неприличное"

Регэксп для обсуждаемой задачи будет такой:
"a.*(?<!fbar)[1-9]\s?(?!xyz)...\b"

где fbar и xyz — упомянутые неприличные слова.
У меня написание этого регэкспа с нуля, без предварительных размышлений, ушло 50 секунд, по секундомеру. Я просто смотрел на русский текст и переводил его почти что слово в слово в регэксп, следи за руками: сначала буква а "а", потом что угодно ".*", потом любая цифра, кроме нуля "[1-9]", только чтоб перед ней не было неприличного слова из четырех букв "(?<!fbar)", потом опциональный пробел "\s?", потом слово из трех букв "...\b", но не неприличное "(?!xyz)".


Ждем решения на пеге и чудо-ДСЛе, с демонстрацией, что они предоставляют такой же уровень удобства и скорости написания.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: PEG vs RegExp
От: fddima  
Дата: 02.07.10 06:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD> общего назначения). Более того, первые ласточки его использования уже есть – создана библиотека LPEG, которая позиционируется как замена регулярных выражений для языка Lua. Однако надеяться на победоносное шествие PEG по господствующим языкам и фреймворкам (Java, .NET, C++) не приходится. Почему? Вернитесь к началу сообщения.

Известно почему.
Хочется по-месту набить небольшое выражение, пусть даже из какой-то более-менее общей стандартной среды, а не долго набивать грамматику что бы в итоге обработать десять симоволов разобрав их на компоненты.
Если бы была альтернатива регэкспам позволяющая это делать — было бы здорово.
Re[12]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.07.10 07:44
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>>>Ну и как бы на твоем DSL выглядел бы вот такой запрос: "сначала буква а, потом что угодно, потом любая цифра, кроме нуля, только чтоб перед ней не было неприличного слова из четырех букв, потом опциональный пробел, потом слово из трех букв, но не неприличное". Напоминаю для сравнения — регэксп записывается в одну строку, так что достаточно предоставить юзеру поле ввода, и все.

J>>>ЗЫ регэкспы — это тоже DSL, причем широкоизвестный и общепринятый, изобретенный как раз для этих целей. Так что, раз уж ты пришел к идее DSL — может, лучше использовать стандартный?
G>>Для записи матчинга по всему урлу regexp неудобен. ИМХО удобнее записывать предикаты для частей.
J>Я пример увижу? А то пока только какие-то сферические предикаты в вакууме, которые все сделают. Где псевдокод на чудо-ДСЛе, который удобнее, чем регэкспы?
Не, мне лениво придумывать.

J>>>Ну, генетики этим реально пользуются, насколько я знаю.

G>>Ну я видел пример округления чисел на regex (на форуме пробегал), но не думаю что так стоит делать.
J>А в Киеве дядька. При чем тут округление чисел?
При том что так тоже можно использовать regex, только это далеко не самая хорошая идея.

G>>Ты обработку ошибок не учел.

J>А у тебя где обработка ошибок?
J>Там иф стоит, видел? А Питон просто бросит исключение, но и в нем можно иф заюзать.
J>А вот ты длину строки не проверил — на шарпе/яве оно, может, и ничего, а на С/С++ будет пробежка по памяти с фейерверками.
J>А с проверкой строки — будет тот же самый иф.
J>И чем "if ( x.Length > 3 ) return x.Substring(3, x.Length — 3)" лучше, чем "if ( match( ... ) ) return group(1)", я не вижу.
J>Зато вижу, чем хуже — неуниверсальностью, троекратным повторением числа 3 (что легко приводит к ошибкам, если понадобится заменить, скажем, на 5), необходимостью перекомпиляции, ели понадобится что-то другое, невозможностью задать алгоритм сравнения извне.
Неуниверсальность это хорошо, универсальные всемогучки неудобно использовать (практически подтвержденный факт).
В реальном коде будет сделан extension, работающий для любого числа, а вот с regex гораздо сложнее будет.
Алгоритм сравнения чего?


G>>Еще раз: в 99% случаев паттерны фиксированы при компиляции. Даже если не фиксированы, то более мощная и читаемая грамматика гораздо лучше "птичьего языка" регэкспов.

J>это в твоих задачах они фиксированы. А если не фиксированы, то я все еще жду примера мощного и читаемого запроса, который зарулит регэксп для банального поиска текста по файлам.
Полнотекстовый поиск со словоформами зарулит вообще все. См гугл, яндекс итп.

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

J>>>>>А с грамматикой ты что будешь делать?
G>>>>Тоже самое.
J>>>То же самое что? Что пользователь будет вводить и в каком виде?
G>>Для peg регулярное подмножество записывается почти также, как и в регэкспах, поэтому тоже самое будет.
J>пример, плиз. Задача поставлена в начале прошлого сообщения.
J>А то какие-то абстрактные рассуждения то о ПЕГе, то вообще о своем собственном DSL, а примера нет как нет.
http://en.wikipedia.org/wiki/Parsing_expression_grammar
Грамматика — такой же текст. Пойми это наконец.

J>>>З.Ы. Еще раз — я не нападаю на грамматики, я сам их широко использую в виде Спирита.

J>>>Но для простых вещей регэкспы заруливают грамматики именно с точки зрения простоты, компактности и того, что это — просто строчка. Т.е. если мне нужно поискать что-нть в файлах (grep), или настроить в программе логику в зависимости от того, как выглядит некая строчка (чтоб алгоритм выбора лежал в конфиге и не нужно было перекомпилировать на каждый чих; это была реальная задача на работе, кстати, решение заняло 2 строчки, как ты уже видел выше) — тут регэкспы рулят.
G>>У тебя сразу много заблуждений собрано в одном месте.
G>>1)Грамматика PEG такая же строчка, особенно если описываешь регулярный язык
J>пример, плиз. Сравним "такие же" строчки.

G>>2)Современные регэкспы обладают большей мощностью, чем регулярные грамматики и используют тот же самый поиск с возвратом для матча. При этом все это нагружается хреновым синтаксисом и регэкспы становятся write-only. Поэтому никаких преимуществ сложных регэкспов перед PEG нету. Для простых смотри п1.

G>>3)99% паттернов в программах статичны, поэтому преимущества "просто строчки" становятся на самом деле недостатками из-за плохой читаемости "просто строчек" и необходимости компиляции. В nemerle предлагается compile-time генерация парсера.
J>99% _твоих_ паттернов статичны — так правильнее.
Да не только, я еще коллег опросил.

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

J>Сеанс телепатии не удался. Я не предлагаю использовать регэкспы для парсинга языков с развитой грамматикой — для этого нужно использовать грамматики.
J>Я лишь все эти два дня говорю лишь о том, что всему свое место, есть ниша и для грамматик, и для регэкспов, и для готовых plug-n-play парсеров типа msxml. А вы меня тут на пару с Владом пытаетесь убедить, что для регэкспов ниши нету, потому что пег рулит "ваще везде" и может заменить регэкспы опять же "ваще везде". Причем без примеров, которые бы могли меня раз и навсегда убедить отказаться от регэкспов и стереть с диска grep.
Ты еще не понял что регулярные regexp_ы — строгое подмножество PEG, а там где они нерегулярны, то лучше сразу использовать PEG, а не птичий язык с lookahead паттернами.

J>ЗЫ. На всякий случай напоминаю задачу:

J>"сначала буква а, потом что угодно, потом любая цифра, кроме нуля, только чтоб перед ней не было неприличного слова из четырех букв, потом опциональный пробел, потом слово из трех букв, но не неприличное"


J>Регэксп для обсуждаемой задачи будет такой:

J>
J>"a.*(?<!fbar)[1-9]\s?(?!xyz)...\b"
J>

J>где fbar и xyz — упомянутые неприличные слова.
J>У меня написание этого регэкспа с нуля, без предварительных размышлений, ушло 50 секунд, по секундомеру. Я просто смотрел на русский текст и переводил его почти что слово в слово в регэксп, следи за руками: сначала буква а "а", потом что угодно ".*", потом любая цифра, кроме нуля "[1-9]", только чтоб перед ней не было неприличного слова из четырех букв "(?<!fbar)", потом опциональный пробел "\s?", потом слово из трех букв "...\b", но не неприличное "(?!xyz)".
J>Ждем решения на пеге и чудо-ДСЛе, с демонстрацией, что они предоставляют такой же уровень удобства и скорости написания.
Ты удивишься:
НеприличноеСловоИз3Букв <- "ху*"|..
НеприличноеСловоИз4Букв <- "жопа"|...
Решение <- 'a' .* !НеприличноеСловоИз3Букв  ['1'-'9'] ws? !НеприличноеСловоИз4Букв

Ну тут могут быть отличия в зависимости от реализации PEG. Кроме того PEG (и не только) парсер может не только проматчить строку, но и вытащить из нее данные (собственно распарсить).
Re[13]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 02.07.10 09:31
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Не, мне лениво придумывать.

ОК, бог с ним, с ДСЛем.

J>>>>Ну, генетики этим реально пользуются, насколько я знаю.

G>>>Ну я видел пример округления чисел на regex (на форуме пробегал), но не думаю что так стоит делать.
J>>А в Киеве дядька. При чем тут округление чисел?
G>При том что так тоже можно использовать regex, только это далеко не самая хорошая идея.
Тем не менее в биоинформатике это промышленное решение:
http://en.wikipedia.org/wiki/Fasta_format

G>Алгоритм сравнения чего?

Ну не сравнение, плохое слово, согласен. Выяснение неких свойств текста. Или вырезание определенного куска текста по определенному правилу. Или преобразование текста по определенным правилам.

G>Полнотекстовый поиск со словоформами зарулит вообще все. См гугл, яндекс итп.

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

G>Грамматика — такой же текст. Пойми это наконец.

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

Кстати, а что там с обратными ссылками? Их, вроде как, в пеге вообще нету, а это — вещь очень часто нужная.

J>>>>З.Ы. Еще раз — я не нападаю на грамматики, я сам их широко использую в виде Спирита.


G>Ты еще не понял что регулярные regexp_ы — строгое подмножество PEG, а там где они нерегулярны, то лучше сразу использовать PEG, а не птичий язык с lookahead паттернами.

их главная особенность — они крайне компактны. Птичьи lookahead-ы не более птичьи, чем звездочки и вопросики.

J>>ЗЫ. На всякий случай напоминаю задачу:

J>>"сначала буква а, потом что угодно, потом любая цифра, кроме нуля, только чтоб перед ней не было неприличного слова из четырех букв, потом опциональный пробел, потом слово из трех букв, но не неприличное"


J>>Регэксп для обсуждаемой задачи будет такой:

J>>
J>>"a.*(?<!fbar)[1-9]\s?(?!xyz)...\b"
J>>

J>>Ждем решения на пеге и чудо-ДСЛе, с демонстрацией, что они предоставляют такой же уровень удобства и скорости написания.
G>Ты удивишься:
G>
G>НеприличноеСловоИз3Букв <- "ху*"|..
G>НеприличноеСловоИз4Букв <- "жопа"|...
G>Решение <- 'a' .* !НеприличноеСловоИз3Букв  ['1'-'9'] ws? !НеприличноеСловоИз4Букв
G>

Жесть.
Я правильно понимаю, что ты юзеру будешь показывать многострочное окошечко с текстом, в котором он должен будет эти три строчки набрать?
И продумывать приоритеты там, где он в регэкспе просто поставил бы скобки с том месте, где оно ему понадобилось??
И так каждый раз?
Кстати, ws откуда взялась? это, видимо, будет 4-я строчка?
И где слово из трех букв (с контролем, что после трех букв — граница слова, т.е. \b в регэкспе)?

Да, и поясни, плиз, как это ты так написал !НеприличноеСловоИз4Букв? Я так понимаю, по правилам де Моргана, это будет означать "НЕ чччч И НЕ ....", так? или нет? Если да, то это значит, что вообще ничего не сматчится.

G>Ну тут могут быть отличия в зависимости от реализации PEG. Кроме того PEG (и не только) парсер может не только проматчить строку, но и вытащить из нее данные (собственно распарсить).

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

А раз уж ты заговорил о вытаскивании данных: во всяких перлах простое преобразование текста при помощи той группировки вообще становится детской задачей, например, поменять два слова местами:
s/(\w+) (\w+)/\2 \1/

заменить std::string< char, char_traits< char >, allocator< char > > на просто std::string< char >, но только при условии, что во всех трех местах используется один и тот же тип (стандартная задача для тех, кто пытается прорваться через сообщения компилятора С++):
s/std::string< ([a-zA-Z_]\w*), char_traits< \1 >, allocator< \1 > >/std::string< \1 >/g

Извини, но я пока что не вижу, как ПЕГ может по выразительности зарулить регэкспы в _таких_ вот (реальных!) задачах.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[7]: PEG vs RegExp
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.07.10 10:19
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Там АСТ создается руками, а не парсером (и тут же херится). Зачем они это делют я незнаю.


Затем что это пример. В реальности AST нужно практически всегда.

VD>Я вооще не понимаю зачем в генерированном коде использовать высокоуровневые конструкции.


Думаю, для простоты и быстроты получения результата. Ну и есть еще отладка.

VD>Кстати, что касается объема кода — это отличная демонстрация того как и где рулит функциональный подход .


На объем генерируемого кода — плевать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
AVK Blog
Re[14]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.07.10 10:23
Оценка:
Здравствуйте, jazzer, Вы писали:

G>>Полнотекстовый поиск со словоформами зарулит вообще все. См гугл, яндекс итп.

J>даже близко он не рулит. Что, если мне надо найти слова, начинающиеся на regex_? Чтоб он мне вернул regex_match, regex_search и т.д?
J>Он рулит, только когда ты знаешь слова, и когда гугль знает все словоформы, а он их сплошь и рядом не знает. Например, слово Сибирь в японском пишут и как "сибэриа", и как "сибэрия". Гугль знает только первый вариант (по крайней мере, так было, когда я в последний раз искал).
J>А при работе с сорцами полнотекстовый поиск по целым словам и словоформам вообще не в тему.
тем не менее гугль ищет именно так, а не с помощью регэкспов.

G>>Грамматика — такой же текст. Пойми это наконец.

J>Слушай, сколько можно мне отказывать в мыслительных способностях? Это оскорбительно, в конце концов. Почему ты думаешь, что я этого не понимаю?
J>Да, это большой многострочный текст, стоит чуть приподнять голову от самых элементарных выражений.
J>Особенно в случае Влада, который не собирается предоставлять распространенных примитивов — там еще и примитивы придется самому объявлять.

J>Кстати, а что там с обратными ссылками? Их, вроде как, в пеге вообще нету, а это — вещь очень часто нужная.

Вместо обратных ссылок надо использовать вывод парсера.


J>>>>>З.Ы. Еще раз — я не нападаю на грамматики, я сам их широко использую в виде Спирита.


G>>Ты еще не понял что регулярные regexp_ы — строгое подмножество PEG, а там где они нерегулярны, то лучше сразу использовать PEG, а не птичий язык с lookahead паттернами.

J>их главная особенность — они крайне компактны.
Это же их главный недостаток, потому что читаемость ужасная.

J>>>ЗЫ. На всякий случай напоминаю задачу:

J>>>"сначала буква а, потом что угодно, потом любая цифра, кроме нуля, только чтоб перед ней не было неприличного слова из четырех букв, потом опциональный пробел, потом слово из трех букв, но не неприличное"


J>>>Регэксп для обсуждаемой задачи будет такой:

J>>>
J>>>"a.*(?<!fbar)[1-9]\s?(?!xyz)...\b"
J>>>

J>>>Ждем решения на пеге и чудо-ДСЛе, с демонстрацией, что они предоставляют такой же уровень удобства и скорости написания.
G>>Ты удивишься:
G>>
G>>НеприличноеСловоИз3Букв <- "ху*"|..
G>>НеприличноеСловоИз4Букв <- "жопа"|...
G>>Решение <- 'a' .* !НеприличноеСловоИз3Букв  ['1'-'9'] ws? !НеприличноеСловоИз4Букв
G>>

J>Жесть.
J>Я правильно понимаю, что ты юзеру будешь показывать многострочное окошечко с текстом, в котором он должен будет эти три строчки набрать?
Нет, можно и в одну строчку, непосредственно подставив нетерминалы в результат.

J>И продумывать приоритеты там, где он в регэкспе просто поставил бы скобки с том месте, где оно ему понадобилось??

J>И так каждый раз?
Нет, зависит от реализации.

J>Кстати, ws откуда взялась? это, видимо, будет 4-я строчка?

Нет, зависит от реализации, я бы не стал пользоваться парсером (PEG или любым другим) у которого нету алиасов для пробельных символов.

J>И где слово из трех букв (с контролем, что после трех букв — граница слова, т.е. \b в регэкспе)?

Упустил. Аналогично пробельным символам.

J>Да, и поясни, плиз, как это ты так написал !НеприличноеСловоИз4Букв? Я так понимаю, по правилам де Моргана, это будет означать "НЕ чччч И НЕ ....", так? или нет? Если да, то это значит, что вообще ничего не сматчится.

http://en.wikipedia.org/wiki/Parsing_expression_grammar

G>>Ну тут могут быть отличия в зависимости от реализации PEG. Кроме того PEG (и не только) парсер может не только проматчить строку, но и вытащить из нее данные (собственно распарсить).

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

J>А для сложных грамматик я РЕ и не предлагаю.

А email — сложная грамматика или нет? Ты же видел re для email и тоже самое в виде PEG.


J>А раз уж ты заговорил о вытаскивании данных: во всяких перлах простое преобразование текста при помощи той группировки вообще становится детской задачей, например, поменять два слова местами:

J>
J>s/(\w+) (\w+)/\2 \1/
J>

Да уж, очень "практическая" задача.
Делается элементарно с помощью вывода. Как оно записывается записывается зависит от реализации.
в идеале так:
w1:w+ w2:w+ => w2.Value+' '+w1.Value;



J>заменить std::string< char, char_traits< char >, allocator< char > > на просто std::string< char >, но только при условии, что во всех трех местах используется один и тот же тип (стандартная задача для тех, кто пытается прорваться через сообщения компилятора С++):

J>
J>s/std::string< ([a-zA-Z_]\w*), char_traits< \1 >, allocator< \1 > >/std::string< \1 >/g
J>

J>Извини, но я пока что не вижу, как ПЕГ может по выразительности зарулить регэкспы в _таких_ вот (реальных!) задачах.
Если будет не char, type<param> твой re начинает сосать, потому что язык для своих экспериментов ты взял нерегулярный.
А Peg пофигу, он почти все парсит.
Я бы в таком случае променял "простоту" re, на коректность более мощного парсера.
Re[15]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 02.07.10 11:23
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>А при работе с сорцами полнотекстовый поиск по целым словам и словоформам вообще не в тему.

G>тем не менее гугль ищет именно так, а не с помощью регэкспов.

Я знаю, что Гугль не способен искать по регэкспам, равно как и по ПЕГам и прочим веселым радостям. Это что-то доказывает? Тебе всегда хватает гугла? Мне вот не всегда, особенно когда ищешь не просто слова.
Ты по своим сорцам тоже гуглом шаришься? Со словоформами?
Просто гугл заточен под другой сценарий использования (поиск слов в текстах на естественных языках), равно как и РЕ заточены под свой сценарий.

J>>Кстати, а что там с обратными ссылками? Их, вроде как, в пеге вообще нету, а это — вещь очень часто нужная.

G>Вместо обратных ссылок надо использовать вывод парсера.
Не, это несерьезно. Мне нужно, чтоб это было именно в парсере, т.е. если обратная ссылка не сматчилась, то должен произойти откат до ближайшей альтернативы.
Я так понимаю, ты вначале предлагаешь сматчить все, а потом проверить части на совпадение, так? Поправь, если не так.

J>>>>>>З.Ы. Еще раз — я не нападаю на грамматики, я сам их широко использую в виде Спирита.


G>>>Ты еще не понял что регулярные regexp_ы — строгое подмножество PEG, а там где они нерегулярны, то лучше сразу использовать PEG, а не птичий язык с lookahead паттернами.

J>>их главная особенность — они крайне компактны.
G>Это же их главный недостаток, потому что читаемость ужасная.
Ну, бесплатным ничто не бывает. Но "ужасная" — имхо, это преувеличение. Паттерн для lookahead: (?=xxx) — где тут ужасная читаемость? Чем она ужаснее [a-z]*?
Я думаю, пег будет не менее ужасным, если записать его в одну строчку.
А если писать в несколько строчек — то и регэксп тоже замечательно разбивается и собирается потом простой конкатенацией.
Хотя, естественно, мощность регэкспа не так велика, как мощность полноценного парсера (это и так очевидно, но повторить нелишне, чтоб не заподозрили).

J>>>>ЗЫ. На всякий случай напоминаю задачу:

J>>>>"сначала буква а, потом что угодно, потом любая цифра, кроме нуля, только чтоб перед ней не было неприличного слова из четырех букв, потом опциональный пробел, потом слово из трех букв, но не неприличное"

J>>>>Регэксп для обсуждаемой задачи будет такой:

J>>>>
J>>>>"a.*(?<!fbar)[1-9]\s?(?!xyz)...\b"
J>>>>

G>>>
G>>>НеприличноеСловоИз3Букв <- "ху*"|..
G>>>НеприличноеСловоИз4Букв <- "жопа"|...
G>>>Решение <- 'a' .* !НеприличноеСловоИз3Букв  ['1'-'9'] ws? !НеприличноеСловоИз4Букв
G>>>

J>>Жесть.
J>>Я правильно понимаю, что ты юзеру будешь показывать многострочное окошечко с текстом, в котором он должен будет эти три строчки набрать?
G>Нет, можно и в одну строчку, непосредственно подставив нетерминалы в результат.
Так и что у тебя получится-то?

J>>Кстати, ws откуда взялась? это, видимо, будет 4-я строчка?

G>Нет, зависит от реализации, я бы не стал пользоваться парсером (PEG или любым другим) у которого нету алиасов для пробельных символов.
Ок, принято. Я бы тоже не стал.

G>>>Ну тут могут быть отличия в зависимости от реализации PEG. Кроме того PEG (и не только) парсер может не только проматчить строку, но и вытащить из нее данные (собственно распарсить).

J>>На простом уровне РЕ умеют вытаскивать не хуже полноценного парсера при помощи группировки — заключи то, что тебе надо, в скобки — и оно в твоем распоряжении.
G>Это всего лишь строки, они даже не структурированы будут.
Так мне и не нужна структура! Если она мне будет нужна — я возьму полноценный парсер, но она мне не нужна, мне нужно просто то, что в скобочках, как последовательность символов, и все.

J>>А для сложных грамматик я РЕ и не предлагаю.

G>А email — сложная грамматика или нет? Ты же видел re для email и тоже самое в виде PEG.
Я имею в виду, самостоятельно писать не предлагаю.
email я сам никогда писать не буду, возьму готовый, и мне пофиг, на чем он будет написан — на пеге, на РЕ или вообще брут-форсом.
То же относится и к другим популярным форматам, XML, например.
Но если мне нужно найти что-то простое, или по-быстрому прошариться по сорцам в поисках чего-то конкретного — удобнее регэкспов мне пока-что ничего не попадалось. Я, естественно, имею в виду перловые регэкспы, а не то убожество, которое живет в продуктах мелкософта.

J>>А раз уж ты заговорил о вытаскивании данных: во всяких перлах простое преобразование текста при помощи той группировки вообще становится детской задачей, например, поменять два слова местами:

J>>
J>>s/(\w+) (\w+)/\2 \1/
J>>

G>Да уж, очень "практическая" задача.
Практическая задача — это было про вывод компилятора.
G>Делается элементарно с помощью вывода. Как оно записывается записывается зависит от реализации.
G>в идеале так:
G>
G>w1:w+ w2:w+ => w2.Value+' '+w1.Value;
G>

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

J>>заменить std::string< char, char_traits< char >, allocator< char > > на просто std::string< char >, но только при условии, что во всех трех местах используется один и тот же тип (стандартная задача для тех, кто пытается прорваться через сообщения компилятора С++):

J>>
J>>s/std::string< ([a-zA-Z_]\w*), char_traits< \1 >, allocator< \1 > >/std::string< \1 >/g
J>>

J>>Извини, но я пока что не вижу, как ПЕГ может по выразительности зарулить регэкспы в _таких_ вот (реальных!) задачах.
G>Если будет не char, type<param> твой re начинает сосать, потому что язык для своих экспериментов ты взял нерегулярный.
Я просто проиллюстрировать, в каких случаях нужны обратные ссылки. А так конечно, надо бы еще вместо каждого пробела поставить $ws, который будет парсить любые пробелы плюс комментарии.
В реальном скрипте, который я использую для разбора сообщений об ошибках, у меня вместо кондового \w+ стоит веселое выражение с $RE{balanced}, которое считает скобки. http://search.cpan.org/~abigail/Regexp-Common-2010010201/lib/Regexp/Common/balanced.pm
И которое, естественно, сохранено в переменную и просто подставляется во все места. Так что все у меня просто замечательно парсится, и никто ничего не сосет. И текст скрипта вполне читабельный. Так что мимо.
Вернемся к нашей строке. Я так понимаю, что ПЕГ для того, чтоб сматчить такой std::string, не существует?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[16]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.07.10 11:59
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>>>А при работе с сорцами полнотекстовый поиск по целым словам и словоформам вообще не в тему.

G>>тем не менее гугль ищет именно так, а не с помощью регэкспов.

J>Я знаю, что Гугль не способен искать по регэкспам, равно как и по ПЕГам и прочим веселым радостям. Это что-то доказывает? Тебе всегда хватает гугла? Мне вот не всегда, особенно когда ищешь не просто слова.

J>Ты по своим сорцам тоже гуглом шаришься? Со словоформами?
Нет, у меня есть architecture explorer.

J>Просто гугл заточен под другой сценарий использования (поиск слов в текстах на естественных языках), равно как и РЕ заточены под свой сценарий.

Именно. Основной сценарий использования regex — поиск в регулярном языке. Естественный текст не является даже КС-языком, не то что регулярным. Поэтому искать в нем с помощью regex не стоит и гугл об этом знает.
Весь прикол в том что в PEG регулярное подмножество записывается почти также, как в regex, а за пределами регулярных языков PEG начинает рулить со страшной силой. Поэтому область применения regex при наличии хорошего и удобного генератора PEG сужается очень сильно.

В Haskell есть Parsec — парсер-комбинаторы, которые по сути не отличаются от PEG, так вот в хаскеле парсинг делается именно им,а не регулярками, которые в нем тоже есть.

J>>>Кстати, а что там с обратными ссылками? Их, вроде как, в пеге вообще нету, а это — вещь очень часто нужная.

G>>Вместо обратных ссылок надо использовать вывод парсера.
J>Не, это несерьезно. Мне нужно, чтоб это было именно в парсере, т.е. если обратная ссылка не сматчилась, то должен произойти откат до ближайшей альтернативы.
J>Я так понимаю, ты вначале предлагаешь сматчить все, а потом проверить части на совпадение, так? Поправь, если не так.
Побойся бога, никто так делать не будет.

J>>>>>>>З.Ы. Еще раз — я не нападаю на грамматики, я сам их широко использую в виде Спирита.


G>>>>Ты еще не понял что регулярные regexp_ы — строгое подмножество PEG, а там где они нерегулярны, то лучше сразу использовать PEG, а не птичий язык с lookahead паттернами.

J>>>их главная особенность — они крайне компактны.
G>>Это же их главный недостаток, потому что читаемость ужасная.
J>Ну, бесплатным ничто не бывает. Но "ужасная" — имхо, это преувеличение. Паттерн для lookahead: (?=xxx) — где тут ужасная читаемость? Чем она ужаснее [a-z]*?
J>Я думаю, пег будет не менее ужасным, если записать его в одну строчку.
Ну его не надо всегда в одну строчку писать

J>А если писать в несколько строчек — то и регэксп тоже замечательно разбивается и собирается потом простой конкатенацией.

Ага, примерно как SQL.

J>>>>>ЗЫ. На всякий случай напоминаю задачу:

J>>>>>"сначала буква а, потом что угодно, потом любая цифра, кроме нуля, только чтоб перед ней не было неприличного слова из четырех букв, потом опциональный пробел, потом слово из трех букв, но не неприличное"

J>>>>>Регэксп для обсуждаемой задачи будет такой:

J>>>>>
J>>>>>"a.*(?<!fbar)[1-9]\s?(?!xyz)...\b"
J>>>>>

G>>>>
G>>>>НеприличноеСловоИз3Букв <- "ху*"|..
G>>>>НеприличноеСловоИз4Букв <- "жопа"|...
G>>>>Решение <- 'a' .* !НеприличноеСловоИз3Букв  ['1'-'9'] ws? !НеприличноеСловоИз4Букв
G>>>>

J>>>Жесть.
J>>>Я правильно понимаю, что ты юзеру будешь показывать многострочное окошечко с текстом, в котором он должен будет эти три строчки набрать?
G>>Нет, можно и в одну строчку, непосредственно подставив нетерминалы в результат.
J>Так и что у тебя получится-то?
Тоже что у тебя.

J>>>Кстати, ws откуда взялась? это, видимо, будет 4-я строчка?

G>>Нет, зависит от реализации, я бы не стал пользоваться парсером (PEG или любым другим) у которого нету алиасов для пробельных символов.
J>Ок, принято. Я бы тоже не стал.

G>>>>Ну тут могут быть отличия в зависимости от реализации PEG. Кроме того PEG (и не только) парсер может не только проматчить строку, но и вытащить из нее данные (собственно распарсить).

J>>>На простом уровне РЕ умеют вытаскивать не хуже полноценного парсера при помощи группировки — заключи то, что тебе надо, в скобки — и оно в твоем распоряжении.
G>>Это всего лишь строки, они даже не структурированы будут.
J>Так мне и не нужна структура! Если она мне будет нужна — я возьму полноценный парсер, но она мне не нужна, мне нужно просто то, что в скобочках, как последовательность символов, и все.
Это тоже стурктура, только простая, далеко не всегда такой простой структуры будет достаточно.
Обычно результаты матча перекладываются потом в какой-нить объект.

J>>>А для сложных грамматик я РЕ и не предлагаю.

G>>А email — сложная грамматика или нет? Ты же видел re для email и тоже самое в виде PEG.
J>Я имею в виду, самостоятельно писать не предлагаю.
J>email я сам никогда писать не буду, возьму готовый, и мне пофиг, на чем он будет написан — на пеге, на РЕ или вообще брут-форсом.
J>То же относится и к другим популярным форматам, XML, например.
J>Но если мне нужно найти что-то простое, или по-быстрому прошариться по сорцам в поисках чего-то конкретного — удобнее регэкспов мне пока-что ничего не попадалось. Я, естественно, имею в виду перловые регэкспы, а не то убожество, которое живет в продуктах мелкософта.
Ну потому что ты другого не пробовал (снова Блаб). Я вот в 2010 студии открыл для себя architecture explorer, с тех пор вообще поиском не пользуюсь.

J>>>А раз уж ты заговорил о вытаскивании данных: во всяких перлах простое преобразование текста при помощи той группировки вообще становится детской задачей, например, поменять два слова местами:

J>>>
J>>>s/(\w+) (\w+)/\2 \1/
J>>>

G>>Да уж, очень "практическая" задача.
J>Практическая задача — это было про вывод компилятора.
G>>Делается элементарно с помощью вывода. Как оно записывается записывается зависит от реализации.
G>>в идеале так:
G>>
G>>w1:w+ w2:w+ => w2.Value+' '+w1.Value;
G>>

J>ну так это нужен еще дополнительный язык для программирования вывода.
J>ОК, как оно записывается в твоей любимой реализации?
J>Какая у тебя любимая реализация, кстати?
Нету такой, я парсер-комбинаторами пользуюсь. Надеюсь что vlad и команда изобретут что-нить достойное.


J>>>заменить std::string< char, char_traits< char >, allocator< char > > на просто std::string< char >, но только при условии, что во всех трех местах используется один и тот же тип (стандартная задача для тех, кто пытается прорваться через сообщения компилятора С++):

J>>>
J>>>s/std::string< ([a-zA-Z_]\w*), char_traits< \1 >, allocator< \1 > >/std::string< \1 >/g
J>>>

J>>>Извини, но я пока что не вижу, как ПЕГ может по выразительности зарулить регэкспы в _таких_ вот (реальных!) задачах.
G>>Если будет не char, type<param> твой re начинает сосать, потому что язык для своих экспериментов ты взял нерегулярный.
J>Я просто проиллюстрировать, в каких случаях нужны обратные ссылки. А так конечно, надо бы еще вместо каждого пробела поставить $ws, который будет парсить любые пробелы плюс комментарии.
Обратные ссылки нужны когда язык нерегулярный,а когда язык нерегулярный, то вполне может найтись случай где это re не будет работать.

J>В реальном скрипте, который я использую для разбора сообщений об ошибках, у меня вместо кондового \w+ стоит веселое выражение с $RE{balanced}, которое считает скобки. http://search.cpan.org/~abigail/Regexp-Common-2010010201/lib/Regexp/Common/balanced.pm

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

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

J>Вернемся к нашей строке. Я так понимаю, что ПЕГ для того, чтоб сматчить такой std::string, не существует?
PEG строго мощнее regex, поэтому все что ты сможешь написать с помощью regex, то можно описать с помощью peg.
Как это будет выглядеть — зависит от синтаксиса описания peg (особенно вывода).
Re[17]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 02.07.10 12:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>>>Кстати, а что там с обратными ссылками? Их, вроде как, в пеге вообще нету, а это — вещь очень часто нужная.

G>>>Вместо обратных ссылок надо использовать вывод парсера.
J>>Не, это несерьезно. Мне нужно, чтоб это было именно в парсере, т.е. если обратная ссылка не сматчилась, то должен произойти откат до ближайшей альтернативы.
J>>Я так понимаю, ты вначале предлагаешь сматчить все, а потом проверить части на совпадение, так? Поправь, если не так.
G>Побойся бога, никто так делать не будет.
Так и? Как это будет выглядеть на ПЕГе? На примере std::string внизу.

J>>>>>>>>З.Ы. Еще раз — я не нападаю на грамматики, я сам их широко использую в виде Спирита.


J>>А если писать в несколько строчек — то и регэксп тоже замечательно разбивается и собирается потом простой конкатенацией.

G>Ага, примерно как SQL.
Кстати, раз уж ты вспомнил про SQL — вот они за каким-то лядом сделали свой собственный ублюдочный синтаксис для LIKE.
Хорошо хоть, в SQL-99 ввели хоть какое-то подобие нормальных регэкспов.

J>>Так мне и не нужна структура! Если она мне будет нужна — я возьму полноценный парсер, но она мне не нужна, мне нужно просто то, что в скобочках, как последовательность символов, и все.

G>Это тоже стурктура, только простая, далеко не всегда такой простой структуры будет достаточно.
G>Обычно результаты матча перекладываются потом в какой-нить объект.
Опять же, это у тебя — обычно. Мне вот это бывает нужно раз в тыщу лет, а "обычно" мне от регэкспов нужно "нашел, посмотрел, преобразовал (опционально) и забыл".

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

G>Ну потому что ты другого не пробовал (снова Блаб). Я вот в 2010 студии открыл для себя architecture explorer, с тех пор вообще поиском не пользуюсь.
Ну, замечание про Блаба я могу тебе и вернуть, ты явно не особо много опыта с регэкспами имел.
Я не видел architecture explorer и даже не слышал о нем, вот только сейчас слышу от тебя, что неудивительно, если он появился только в 2010 студии.
Вполне допускаю, что он умеет хорошо показывать структуру программы. Хотя для С++ он не работает, судя по замечанию на их сайте.
Но если тебе нужно работать с текстом программы просто как с текстом — что студия для этого предлагает?
Стандартная задача вот была для меня в последний год — скопировать кусок из документа по протоколу (или вообще из письма) и прогнать его через регэксп, который я пишу тут же, благо редактор позволяет — генерится текст программы.
плюс твой замечательный architecture explorer умеет парсить логи, журналы и прочая?
grep вот с перлом умеют, им вообще пофиг, что парсить.
Мне что, для каждого лог-файла грамматику изобретать и потом поддерживать ее, когда я за минуту напишу регэксп в режиме REPL (потому что я сразу же вижу, матчит ли он то, что мне нужно) и добуду информацию, которая мне понадобилась сейчас (и вряд ли понадобится вновь)?

J>>>>заменить std::string< char, char_traits< char >, allocator< char > > на просто std::string< char >, но только при условии, что во всех трех местах используется один и тот же тип (стандартная задача для тех, кто пытается прорваться через сообщения компилятора С++):

J>>>>
J>>>>s/std::string< ([a-zA-Z_]\w*), char_traits< \1 >, allocator< \1 > >/std::string< \1 >/g
J>>>>

J>>>>Извини, но я пока что не вижу, как ПЕГ может по выразительности зарулить регэкспы в _таких_ вот (реальных!) задачах.

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

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

J>>В реальном скрипте, который я использую для разбора сообщений об ошибках, у меня вместо кондового \w+ стоит веселое выражение с $RE{balanced}, которое считает скобки. http://search.cpan.org/~abigail/Regexp-Common-2010010201/lib/Regexp/Common/balanced.pm

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

J>>Вернемся к нашей строке. Я так понимаю, что ПЕГ для того, чтоб сматчить такой std::string, не существует?

G>PEG строго мощнее regex, поэтому все что ты сможешь написать с помощью regex, то можно описать с помощью peg.
G>Как это будет выглядеть — зависит от синтаксиса описания peg (особенно вывода).
Ну вот и получается, что пока что есть только один реальный рабочий инструмент, у которого все есть — это перл и его производные.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[18]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.07.10 12:54
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>>>>>Кстати, а что там с обратными ссылками? Их, вроде как, в пеге вообще нету, а это — вещь очень часто нужная.

G>>>>Вместо обратных ссылок надо использовать вывод парсера.
J>>>Не, это несерьезно. Мне нужно, чтоб это было именно в парсере, т.е. если обратная ссылка не сматчилась, то должен произойти откат до ближайшей альтернативы.
J>>>Я так понимаю, ты вначале предлагаешь сматчить все, а потом проверить части на совпадение, так? Поправь, если не так.
G>>Побойся бога, никто так делать не будет.
J>Так и? Как это будет выглядеть на ПЕГе? На примере std::string внизу.
Не имея под рукой нормального инструмента описывать вывод peg как-то не хочется.


J>>>Так мне и не нужна структура! Если она мне будет нужна — я возьму полноценный парсер, но она мне не нужна, мне нужно просто то, что в скобочках, как последовательность символов, и все.

G>>Это тоже стурктура, только простая, далеко не всегда такой простой структуры будет достаточно.
G>>Обычно результаты матча перекладываются потом в какой-нить объект.
J>Опять же, это у тебя — обычно. Мне вот это бывает нужно раз в тыщу лет, а "обычно" мне от регэкспов нужно "нашел, посмотрел, преобразовал (опционально) и забыл".
Преобразовал во что?

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

G>>Ну потому что ты другого не пробовал (снова Блаб). Я вот в 2010 студии открыл для себя architecture explorer, с тех пор вообще поиском не пользуюсь.
J>Ну, замечание про Блаба я могу тебе и вернуть, ты явно не особо много опыта с регэкспами имел.
Ага, на перле не пишу, так что тонны регэкспов без надобности.

J>Я не видел architecture explorer и даже не слышал о нем, вот только сейчас слышу от тебя, что неудивительно, если он появился только в 2010 студии.

Думаешь не было раньше таких инструментов, которые позволяют работать с кодом не как с текстом, а как с графом?

J>Но если тебе нужно работать с текстом программы просто как с текстом — что студия для этого предлагает?

Банальных find и replace хватает. Остальное делается другими средствами.

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

Ниче не понял. Что из чего и зачем генерится?

J>плюс твой замечательный architecture explorer умеет парсить логи, журналы и прочая?

Он умеет парсить программу, в отличие от regex.

J>grep вот с перлом умеют, им вообще пофиг, что парсить.

J>Мне что, для каждого лог-файла грамматику изобретать и потом поддерживать ее, когда я за минуту напишу регэксп в режиме REPL (потому что я сразу же вижу, матчит ли он то, что мне нужно) и добуду информацию, которая мне понадобилась сейчас (и вряд ли понадобится вновь)?
Синдром молотка.

G>>Обратные ссылки нужны когда язык нерегулярный, а когда язык нерегулярный, то вполне может найтись случай где это re не будет работать.

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


J>>>Вернемся к нашей строке. Я так понимаю, что ПЕГ для того, чтоб сматчить такой std::string, не существует?

G>>PEG строго мощнее regex, поэтому все что ты сможешь написать с помощью regex, то можно описать с помощью peg.
G>>Как это будет выглядеть — зависит от синтаксиса описания peg (особенно вывода).
J>Ну вот и получается, что пока что есть только один реальный рабочий инструмент, у которого все есть — это перл и его производные.
Для тебя он всегда будет один

ЗЫ. Ты с каждым постом все сильнее парадокс Блаба демонстрируешь (невеяно соседней веткой). Даже неинтересно разговаривать становится.
Re[16]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.10 13:05
Оценка:
Здравствуйте, D. Mon, Вы писали:

VD>>В этом нет необходимости. Правда про System.Xml я конечно некорректно высказался. System.Xml — это прстранство имен в котором в том числе есть и очень эффективный (но дико низкоуровневый) XmlTextReader. С ним по скорости трудно конкурировать, но тем не менее Яковский лексер (а XmlTextReader — это только лексер) должен работать с аналогичной скоростью.


DM>Если это лексер, как же он XML с его рекурсивной структурой разбирает?


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

VD>>YACC строит ДКА. Это оначает скорость парсинга O(n). Для PEG-а построить ДКА невозможно.


DM>Там в обоих случаях автомат с магазином (стеком) строится. Простой ДКА (без стека) и LR грамматику не возьмет.


Ага. Но производительность у него очень близка к линейной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.10 13:22
Оценка:
Здравствуйте, jazzer, Вы писали:

VD>>В каких обвинителях? Я просто заметил, что средство реализации (метапрограммировние на шаблонах) не очень хорошо подходит для решения задачи.

J>Это в контексте Немерле. А в контексте С++ — замечательно подходит.

Я рассматриваю задачи исключительно в контексте самой задачи.

VD>>На С++ был только один нормальный выход. Написать библиотеку которая бы делала все чтонужно принимая грамматики в виде строки.

J>Как ты в таком случае обеспечишь semantic actions?

Что-нить на событиях залудить. Для немерлового макроса мы эту задачу решили. Более того, в последствии, при обсуждении следующего поколения макросов было придумано еще более красивое решение. Но оно уже точно реализуемо только в рамках мощной макросистемы (в С++ вряд ли удастся повторить). А вариант с событиями реализовать вполне можно.

VD>>Ну, или классический генератор кода + компиляция. Это тоже можно было бы завернуть в библиотечную функцию (вон в дотнете для сериализации в ХМЛ так делают и ничего).

J>дотнет вообще весь динамический и рефлективный, там и классы можно прям в рантайме генерить. Но мы говорим о С++.

Я помню о чем мы говорим. И пример привел не случайно. В нем тупо генерируются исходники (текст) и компилируются с помощью csc.exe. Тоже самое можно делать любым компилятором С++.

J>Насчет классического генератора кода — это очень неудобно, поэтому, как ты и сам отметил в корневом сообщении, этим никто не пользуется.


Согласен. Но можно же все это завернуть в библиотеку которая все автоматизирует.

J>Плюс генератор код никак не взаимодействует с окружением, ибо он за пределами. А грамматика на Спирите — это все тот же С++ (у меня в программе, например, часть грамматики генерилась шаблонами, а еще часть, динамическая — прямо в рантайме).


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

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


Ужас! Столько приседаний и все только ради того чтобы это был обязательно С++?

VD>>А другие компилятора в мговения ока три тонны шаблонов перемалывают.

J>Наверное. Я тебе время компиляции на стареньком gcc 3.4.6 продемонстрировал. Думаю, последний gcc 4.5 будет еще быстрее, учитывая внимание разработчиков именно к скорости перемалывания шаблонов.

Ну, ну.

VD>>Что не читал? Ты спросил делает ли он то же. Я ответил.

J>Ага, замечательный ответ был, про крестик и гармошку.

Какой вопрос, такой ответ. Что еще тут можно ответить?

J>Сразу видно, что человек детально ознакомился с возможностями Спирита и может аргументированно сопоставить его возможности с возможностями своего парсера на Немерле. Надо взять на вооружение.


Я детально с ними не знакомился. Почитал (давно уже), попробовал. Построитель парсеров как построитель парсеров. Синтаксис немного убогий и немного жирный, но в пределах разумного. Что в нем высматривать то?

Полноценный парсер PEG-а Спириту уж точно ни в чем не уступает. Более того алгоритмически они довольно близки.

VD>>А зачем ему вышивать то? Он же не кот Матросскин? Построитель парсер должен строить парсеры. Не больше, не меньше. На входе граммактика и список обработчиков, на выходе готовый парсер. Это он делает. Вот пресетов для парсинга числе и т.п. нет. Это да. Но они и не нужны когда грамматика описывается не на птичьем языке, а нормально.

J>Ага. Вот опишешь 50 раз парсинг вещественного числа по IEEE — и задумаешься, что неплохо бы, наверное, для стандартных примитивов все же готовые парсеры иметь.

J>ЗЫ Давай языковую часть "С++ vs. Nemerle" оставим прямо здесь и продолжим разговор только в контексте тобой же заявленной темы?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 02.07.10 13:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>Так и? Как это будет выглядеть на ПЕГе? На примере std::string внизу.

G>Не имея под рукой нормального инструмента описывать вывод peg как-то не хочется.
В смысле? Ты не способен написать ПЕГ без инструмента?
А мы то, бедные, с регэкспами мучаемся, рожаем их по пять штук в минуту, напряжением только спинного мозга, и безо всяких инструментов

J>>Опять же, это у тебя — обычно. Мне вот это бывает нужно раз в тыщу лет, а "обычно" мне от регэкспов нужно "нашел, посмотрел, преобразовал (опционально) и забыл".

G>Преобразовал во что?
Ну вот как внизу, std::string.

J>>Я не видел architecture explorer и даже не слышал о нем, вот только сейчас слышу от тебя, что неудивительно, если он появился только в 2010 студии.

G>Думаешь не было раньше таких инструментов, которые позволяют работать с кодом не как с текстом, а как с графом?
Были, Rational Rose, например, я с ней работал.
Только вот эти задачи довольно редко мне встречались.

J>>Но если тебе нужно работать с текстом программы просто как с текстом — что студия для этого предлагает?

G>Банальных find и replace хватает. Остальное делается другими средствами.
Ну а мне банальных find и replace не хватает. А вот регэксповых — хватает.

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

G>Ниче не понял. Что из чего и зачем генерится?
что — код программы.
из чего — из левого текста, например, документа или письма.
зачем — потому что за программу мне деньги заплатят.

J>>плюс твой замечательный architecture explorer умеет парсить логи, журналы и прочая?

G>Он умеет парсить программу, в отличие от regex.
Это я уже понял из текста на мелкосайте, не стоило повторять. Хотелось узнать, что он умеет, _кроме_ парсинга программы.

J>>grep вот с перлом умеют, им вообще пофиг, что парсить.

J>>Мне что, для каждого лог-файла грамматику изобретать и потом поддерживать ее, когда я за минуту напишу регэксп в режиме REPL (потому что я сразу же вижу, матчит ли он то, что мне нужно) и добуду информацию, которая мне понадобилась сейчас (и вряд ли понадобится вновь)?
G>Синдром молотка.
Да ты мастер ярлыки навешивать. Ты сам чем логи парсишь-то? Скрипкой? Или ты их не парсишь просто?

G>>>Обратные ссылки нужны когда язык нерегулярный, а когда язык нерегулярный, то вполне может найтись случай где это re не будет работать.

J>>Какое отношение регулярность языка имеет к обратным ссылкам? Нужны обратные ссылки или нет — зависит исключительно от запроса, который ты хочешь сделать.
G>Ты заблуждаешься, регулярные языки парсятся без обратных ссылок.
Блин. Как мне пример с std::string распарсить без обратных ссылок?
Уже 5-й раз говоришь, что можно, а примера нет как нет.

G>>>Как это будет выглядеть — зависит от синтаксиса описания peg (особенно вывода).

J>>Ну вот и получается, что пока что есть только один реальный рабочий инструмент, у которого все есть — это перл и его производные.
G>Для тебя он всегда будет один
Пока я не увижу преимуществ грамматики для таких вот мелких задач — не вижу причин отказываться от регэкспов.
А я их пока что не вижу.
А для крупных задач я и сам грамматики пользую, тут меня убеждать не надо.

G>ЗЫ. Ты с каждым постом все сильнее парадокс Блаба демонстрируешь (невеяно соседней веткой). Даже неинтересно разговаривать становится.

Я, в отличие классического Блаб-программиста, достаточно в своей жизни грамматик пописал. Так что мимо. Но разговаривать действительно становится неинтересно, ибо я тебе реальный пример, а ты мне табун сфероконей в ответ.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[20]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.07.10 13:40
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>>>Так и? Как это будет выглядеть на ПЕГе? На примере std::string внизу.

G>>Не имея под рукой нормального инструмента описывать вывод peg как-то не хочется.
J>В смысле? Ты не способен написать ПЕГ без инструмента?
Стандартного синтаксиса вывода нет, а придумывать не хочу.

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

Ну-ну, роди для email за 5 минут. Он кстати совсем несложный.

J>>>Опять же, это у тебя — обычно. Мне вот это бывает нужно раз в тыщу лет, а "обычно" мне от регэкспов нужно "нашел, посмотрел, преобразовал (опционально) и забыл".

G>>Преобразовал во что?
J>Ну вот как внизу, std::string.
Так у тебя оно некорректно работает.


J>>>Но если тебе нужно работать с текстом программы просто как с текстом — что студия для этого предлагает?

G>>Банальных find и replace хватает. Остальное делается другими средствами.
J>Ну а мне банальных find и replace не хватает. А вот регэксповых — хватает.
Это потому что у тебя нормальных инструментов нету. Ты рефакторинг типа promeote local variable to parameter с помощью регэкспов делаешь?

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

G>>Ниче не понял. Что из чего и зачем генерится?
J>что — код программы.
J>из чего — из левого текста, например, документа или письма.
J>зачем — потому что за программу мне деньги заплатят.
Скопипастить кусок? Теперь для этого regex нужны?

J>>>плюс твой замечательный architecture explorer умеет парсить логи, журналы и прочая?

G>>Он умеет парсить программу, в отличие от regex.
J>Это я уже понял из текста на мелкосайте, не стоило повторять. Хотелось узнать, что он умеет, _кроме_ парсинга программы.
Наверное, и не нужно. Я уже говорил что универсальные всемогучки не нужны, нужни качественные специализированные тулзы.

J>>>grep вот с перлом умеют, им вообще пофиг, что парсить.

J>>>Мне что, для каждого лог-файла грамматику изобретать и потом поддерживать ее, когда я за минуту напишу регэксп в режиме REPL (потому что я сразу же вижу, матчит ли он то, что мне нужно) и добуду информацию, которая мне понадобилась сейчас (и вряд ли понадобится вновь)?
G>>Синдром молотка.
J>Да ты мастер ярлыки навешивать. Ты сам чем логи парсишь-то? Скрипкой? Или ты их не парсишь просто?
Смотря какие логи, многие логи у меня стурктурированом виде лежат (xml, субд). текстовые логи парсить не приходится, обычного поиска хватает.

G>>>>Обратные ссылки нужны когда язык нерегулярный, а когда язык нерегулярный, то вполне может найтись случай где это re не будет работать.

J>>>Какое отношение регулярность языка имеет к обратным ссылкам? Нужны обратные ссылки или нет — зависит исключительно от запроса, который ты хочешь сделать.
G>>Ты заблуждаешься, регулярные языки парсятся без обратных ссылок.
J>Блин. Как мне пример с std::string распарсить без обратных ссылок?
J>Уже 5-й раз говоришь, что можно, а примера нет как нет.
Ну ты достал. Это нерегулярный язык, никак ты его без обратных ссылок не распарсишь.
А конкретно в твоем примере даже со ссылками ты его корректно не распарсишь.


G>>>>Как это будет выглядеть — зависит от синтаксиса описания peg (особенно вывода).

J>>>Ну вот и получается, что пока что есть только один реальный рабочий инструмент, у которого все есть — это перл и его производные.
G>>Для тебя он всегда будет один
J>Пока я не увижу преимуществ грамматики для таких вот мелких задач — не вижу причин отказываться от регэкспов.
J>А я их пока что не вижу.
J>А для крупных задач я и сам грамматики пользую, тут меня убеждать не надо.
Для мелких разницы и так не будет. Кроме того немалая часть этих мелких задач решаются и без regex.

G>>ЗЫ. Ты с каждым постом все сильнее парадокс Блаба демонстрируешь (невеяно соседней веткой). Даже неинтересно разговаривать становится.

J>Я, в отличие классического Блаб-программиста, достаточно в своей жизни грамматик пописал.
Незаметно.
Re[10]: PEG vs RegExp
От: Воронков Василий Россия  
Дата: 02.07.10 13:52
Оценка:
Здравствуйте, jazzer, Вы писали:

J>скомпилировал, полученный объектник весит 102к. При этом половина объектника — это символы для линкера, если их убрать (командой strip) — 54к.


Я не про объектник, а про сами сгенерированные файлы. Т.е. посмотреть, во что раскрываются шаблоны.
Собственно, можно проще — как работает спирит? Он в компайл-тайме создает парсер или же выступает в роли этакого интерпретатора и работает исключительно в рантайме? Могу ли я в рантайме поменять грамматику?
Re[16]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.10 14:02
Оценка:
Здравствуйте, fddima, Вы писали:

F> XmlTextReader это всё же таки парсер и лексера там как такового нет вообще.


Все же это именно лексер. Ну, может с зачатками парсера, но все же структуру ХМЛ-я он не распознает и работает в потоковом режиме.

F> Дичайших оптимизаций в XmlTextReader тоже нет — абсолютно прозрачная работа с входными данными как они есть, без всяких лишних абстракций. В случае с XML это хорошо работает.


Там рукописный код написанный не самыми идиотами. Написать что-то более быстрое будет крайне проблематично.

Если сравнение было с XmlTextReader, то это некорректное сравнение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.10 14:16
Оценка: +1
Здравствуйте, fddima, Вы писали:

F> Известно почему.

F> Хочется по-месту набить небольшое выражение, пусть даже из какой-то более-менее общей стандартной среды, а не долго набивать грамматику что бы в итоге обработать десять симоволов разобрав их на компоненты.

Если речь о паттерне из 5 символов, то не вопрос. Но почему-то обычно регексы очень быстро превращаются в мелких монстров.

F> Если бы была альтернатива регэкспам позволяющая это делать — было бы здорово.


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

Лично я бы предпочел полноценный PEG который можно было бы использовать аналогично тому как это сейчас делается с регулярными выражениями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.10 14:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Затем что это пример. В реальности AST нужно практически всегда.


Какой-то хреновый пример. АСТ там создается не везде и в результате один фиг возвращается значение.
Больше похоже на отсутствие опыта у того кто это писал.

VD>>Я вооще не понимаю зачем в генерированном коде использовать высокоуровневые конструкции.


AVK>Думаю, для простоты и быстроты получения результата. Ну и есть еще отладка.


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

VD>>Кстати, что касается объема кода — это отличная демонстрация того как и где рулит функциональный подход .


AVK>На объем генерируемого кода — плевать.


А я не не о генерируемом. Я об объеме рукописного кода. Генерируемый у нас примерно одинаковый. Только у них генерируется вызов делегатов, а у нас вот такая вот байда:
private __GENERATED_PEG__RULE__mulOrDiv__(pos : int, result : ref Nemerle.Peg.VToken[int], text : string) : int
{
  mutable (c : char) = (NULL);
  _  = c;
  
  {
    
    {
      _  = "Capture[0] (sl:-1): NTerm[mulOrDiv](simplExpr (Term[_N_unnamed_rule_2888](['*', '/']) Term[spaces]([' ']*) simplExpr)*)";
      mutable token_L0_0 = (NULL);
      mutable token_L0_1 = (NULL);
      def newPos = 
      {
        _  = "Sequence[0] (sl:0): simplExpr (Term[_N_unnamed_rule_2888](['*', '/']) Term[spaces]([' ']*) simplExpr)*";
        
        {
          def pos = 
          {
            _  = "Call[0] (sl:0): simplExpr";
            __GENERATED_PEG__RULE__simplExpr__(pos, ref token_L0_0, text)
          };
          if (pos >= 0) 
          {
            _  = "RepeatMin[1] (sl:0): (Term[_N_unnamed_rule_2888](['*', '/']) Term[spaces]([' ']*) simplExpr)*";
            token_L0_1 = SCG.List();
            mutable token_L1_0 = (NULL);
            mutable token_L1_1 = (NULL);
            mutable token_L1_2 = (NULL);
            def rep [] (pos : int)  
            {
              def newPos = 
              {
                _  = "Sequence[0] (sl:1): Term[_N_unnamed_rule_2888](['*', '/']) Term[spaces]([' ']*) simplExpr";
                
                {
                  def pos = 
                  {
                    _  = "CaptureNamedTerminalSymbol[0] (sl:1): Term[_N_unnamed_rule_2888](['*', '/'])";
                    def newPos = 
                    {
                      _  = "Chars[0] (sl:1): ['*', '/']";
                      if (pos < text.Length) 
                      {
                        c = text[pos];
                        if (c == '*' || c == '/') pos + 1; else -1
                      }; else -1
                    };
                    when (newPos >= 0) token_L1_0 = Nemerle.Peg.NToken(pos, newPos, text, "_N_unnamed_rule_2888");
                    newPos
                  };
                  if (pos >= 0) 
                  {
                    def pos = 
                    {
                      _  = "CaptureNamedTerminalSymbol[1] (sl:1): Term[spaces]([' ']*)";
                      def newPos = 
                      {
                        _  = "RepeatMin[0] (sl:1): [' ']*";
                        ();
                        def rep [] (pos : int)  
                        {
                          def newPos = 
                          {
                            _  = "Chars[0] (sl:2): [' ']";
                            if (pos < text.Length) 
                            {
                              c = text[pos];
                              if (c == ' ') pos + 1; else -1
                            }; else -1
                          };
                          if (newPos >= 0) 
                          {
                            ();
                            rep(newPos)
                          }; else pos
                        } : _ ;
                        rep(pos)
                      };
                      when (newPos >= 0) token_L1_1 = Nemerle.Peg.NToken(pos, newPos, text, "spaces");
                      newPos
                    };
                    if (pos >= 0) 
                    {
                      _  = "Call[2] (sl:1): simplExpr";
                      __GENERATED_PEG__RULE__simplExpr__(pos, ref token_L1_2, text)
                    }; else -1
                  }; else -1
                }
              };
              if (newPos >= 0) 
              {
                token_L0_1.Add(token_L1_0, token_L1_1, token_L1_2);
                rep(newPos)
              }; else pos
            } : _ ;
            rep(pos)
          }; else -1
        }
      };
      when (newPos >= 0) result = Nemerle.Peg.VToken(pos, newPos, text, "mulOrDiv", mulOrDiv(token_L0_0, token_L0_1));
      newPos
    }
  }
}
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 04.07.10 03:19
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


J>>скомпилировал, полученный объектник весит 102к. При этом половина объектника — это символы для линкера, если их убрать (командой strip) — 54к.


ВВ>Я не про объектник, а про сами сгенерированные файлы. Т.е. посмотреть, во что раскрываются шаблоны.

А-а-а.. Не, гцц это го не умеет, либо я не знаю как

ВВ>Собственно, можно проще — как работает спирит? Он в компайл-тайме создает парсер или же выступает в роли этакого интерпретатора и работает исключительно в рантайме? Могу ли я в рантайме поменять грамматику?

И то, и другое.
Как я это понимаю: каждый парсер (как выражение) создается в компайл-тайме (там используется либа для DSL-строения Boost.Proto, т.е. в компайл-тайме строится дерево твоего выражения, с которым ты можешь работать, например, пооптимизировать его), но когда ты его засовываешь в boost::spirit::rule, происходит type erasure и остается только виртуальная функция, которую нужно дернуть.
Так что если ты всю грамматику засунешь в одно плюсовое выражение — она будет целиком компайл-таймовая.
Если будешь разбивать на отдельные правила — будет стираться тип и между ними будут вставляться виртуальные вызовы.
Но заодно при этом ты можешь нагенерить таких правил в рантайме, например, загружая из файла, или в цикле, или еще как-нть.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[21]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 04.07.10 03:44
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

J>>В смысле? Ты не способен написать ПЕГ без инструмента?

G>Стандартного синтаксиса вывода нет, а придумывать не хочу.
Ну вы родите стандарт сначала, а там посмотрим.
Потому что регэкспы — это промышленный стандарт уже бог знает сколько десятков лет, и правила вывода в нем есть, всё через те же обратные ссылки, которых в принципе нет в пеге.
Причем не просто стандарт, а удобный практический инструмент для своих задач.

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

G>Ну-ну, роди для email за 5 минут. Он кстати совсем несложный.
Ты любишь по кругу ходить, я вижу.

J>>>>Опять же, это у тебя — обычно. Мне вот это бывает нужно раз в тыщу лет, а "обычно" мне от регэкспов нужно "нашел, посмотрел, преобразовал (опционально) и забыл".

G>>>Преобразовал во что?
J>>Ну вот как внизу, std::string.
G>Так у тебя оно некорректно работает.
У меня оно корректно работает, я уже писал, как.
А вот у тебя оно не работает вообще никак.
Так что если речь идет о том, что можно забить на регэкспы и юзать вместо них ПЕГ, но при этом придется забыть про обратные ссылки — нафиг мне такая замена нужна.

J>>>>Но если тебе нужно работать с текстом программы просто как с текстом — что студия для этого предлагает?

G>>>Банальных find и replace хватает. Остальное делается другими средствами.
J>>Ну а мне банальных find и replace не хватает. А вот регэксповых — хватает.
G>Это потому что у тебя нормальных инструментов нету. Ты рефакторинг типа promeote local variable to parameter с помощью регэкспов делаешь?
Это не работа с текстом, это работа со структурой. Ты вообще читаешь, что тебе пишут?

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

G>>>Ниче не понял. Что из чего и зачем генерится?
J>>что — код программы.
J>>из чего — из левого текста, например, документа или письма.
J>>зачем — потому что за программу мне деньги заплатят.
G>Скопипастить кусок? Теперь для этого regex нужны?
Из скопипасченного куска сделать текст программы. Ты вообще читаешь, что тебе пишут?

G>Наверное, и не нужно. Я уже говорил что универсальные всемогучки не нужны, нужни качественные специализированные тулзы.

Тебе не нужны.
Почему, интересно, ты пользуешься тогда "униварсальной всемогучкой" XML? Будь последовательным, рожай "качественный специализированный" формат под каждый случай использования.

J>>>>grep вот с перлом умеют, им вообще пофиг, что парсить.

J>>>>Мне что, для каждого лог-файла грамматику изобретать и потом поддерживать ее, когда я за минуту напишу регэксп в режиме REPL (потому что я сразу же вижу, матчит ли он то, что мне нужно) и добуду информацию, которая мне понадобилась сейчас (и вряд ли понадобится вновь)?
G>>>Синдром молотка.
J>>Да ты мастер ярлыки навешивать. Ты сам чем логи парсишь-то? Скрипкой? Или ты их не парсишь просто?
G>Смотря какие логи, многие логи у меня стурктурированом виде лежат (xml, субд). текстовые логи парсить не приходится, обычного поиска хватает.
Вот ты смотришь в свой текстовый лог и видишь, что в нем содержится некая информация, которую неплохо бы собрать и обработать, чтобы выяснить определенный аспект работы программы. Я допускаю, что ты полезешь в программу и сделаешь отдельный логгер, который эту информацию будет складывать в СУБД для последующего анализа, и со следующего релиза у тебя будет все хорошо — но с существующими логами ты что будешь делать? Или в помойку те данные, которые в них содержатся? С регэкспами такая задача решается за минуты, буквально. Причем как задача просто унификации данных (например, преобразование в CSV, чтоб их можно было потом в ту же СУБД все скопом загнать или в Excel скопипастить), так и собственно обработка, если ты используешь регэкспы не сами по себе, а в составе какого-то мощного инструмента типа perl. А что ты будешь делать с этими данными, которые сейчас лежат в логах в неструктурированном виде и, возможно, в разном формате, если от разных подсистем?

G>>>Ты заблуждаешься, регулярные языки парсятся без обратных ссылок.

J>>Блин. Как мне пример с std::string распарсить без обратных ссылок?
J>>Уже 5-й раз говоришь, что можно, а примера нет как нет.
G>Ну ты достал. Это нерегулярный язык, никак ты его без обратных ссылок не распарсишь.
G>А конкретно в твоем примере даже со ссылками ты его корректно не распарсишь.
Понятно. ПЕГ не может распарсить пример с обратными ссылками, так и запишем. И это предлагается в качестве тотальной замены регэкспам.

G>Для мелких разницы и так не будет. Кроме того немалая часть этих мелких задач решаются и без regex.

Даже для мелких, но с обратными ссылками, ПЕГ сливает.

G>>>ЗЫ. Ты с каждым постом все сильнее парадокс Блаба демонстрируешь (невеяно соседней веткой). Даже неинтересно разговаривать становится.

J>>Я, в отличие классического Блаб-программиста, достаточно в своей жизни грамматик пописал.
G>Незаметно.
Ага. От обсуждения технологий плавно перешли к обсуждению моей скромной персоны. Это правильно, надо раньше было. "У регэкспов есть своя область применения! — Блаб детектед!"
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[17]: PEG vs RegExp
От: fddima  
Дата: 04.07.10 21:40
Оценка:
Здравствуйте, VladD2, Вы писали:

F>> XmlTextReader это всё же таки парсер и лексера там как такового нет вообще.

VD>Все же это именно лексер. Ну, может с зачатками парсера, но все же структуру ХМЛ-я он не распознает и работает в потоковом режиме.
При чём тут потоковый режим? Лексер не может раскрывать энтити — XmlTextReader это делает.

F>> Дичайших оптимизаций в XmlTextReader тоже нет — абсолютно прозрачная работа с входными данными как они есть, без всяких лишних абстракций. В случае с XML это хорошо работает.

VD>Там рукописный код написанный не самыми идиотами. Написать что-то более быстрое будет крайне проблематично.
Я и говорю — что кардинально быстрее — нет, не напишешь. Все оптимизации которые используются XmlTextReader-ом, для меня лично — очевидны. В основном это: не делать лишних проверок при обработке следующего символа, и уменьшение бранчинга проца. Всего остального малой кровью не избежать. Плюс ко всему: поведение сильно зависит от настроек и некоторые из оптмизаций доступны только для определенных конфигураций.
Re[11]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 05.07.10 01:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>В каких обвинителях? Я просто заметил, что средство реализации (метапрограммировние на шаблонах) не очень хорошо подходит для решения задачи.

J>>Это в контексте Немерле. А в контексте С++ — замечательно подходит.
VD>Я рассматриваю задачи исключительно в контексте самой задачи.
Хорошая фраза, надо запомнить

VD>>>На С++ был только один нормальный выход. Написать библиотеку которая бы делала все чтонужно принимая грамматики в виде строки.

J>>Как ты в таком случае обеспечишь semantic actions?

VD>Что-нить на событиях залудить. Для немерлового макроса мы эту задачу решили. Более того, в последствии, при обсуждении следующего поколения макросов было придумано еще более красивое решение. Но оно уже точно реализуемо только в рамках мощной макросистемы (в С++ вряд ли удастся повторить). А вариант с событиями реализовать вполне можно.

Можешь кинуть линк, как это сделано на событиях в Немерле сейчас, пожалуйста? Чтоб мне самому не искать.
А то, что Немерле макросистема мощная — так с этим, вроде, и не спорит никто.

VD>>>Ну, или классический генератор кода + компиляция. Это тоже можно было бы завернуть в библиотечную функцию (вон в дотнете для сериализации в ХМЛ так делают и ничего).

J>>дотнет вообще весь динамический и рефлективный, там и классы можно прям в рантайме генерить. Но мы говорим о С++.

VD>Я помню о чем мы говорим. И пример привел не случайно. В нем тупо генерируются исходники (текст) и компилируются с помощью csc.exe. Тоже самое можно делать любым компилятором С++.

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

J>>Насчет классического генератора кода — это очень неудобно, поэтому, как ты и сам отметил в корневом сообщении, этим никто не пользуется.

VD>Согласен. Но можно же все это завернуть в библиотеку которая все автоматизирует.
Ну, это ж не Немерле, в котором прямо из компилятора можно внешние программы звать
Или ты что-то другое имеешь в виду под библиотекой?

J>>Плюс генератор код никак не взаимодействует с окружением, ибо он за пределами. А грамматика на Спирите — это все тот же С++ (у меня в программе, например, часть грамматики генерилась шаблонами, а еще часть, динамическая — прямо в рантайме).

VD>Я уже говорил, что с точки зрения доступности решение на шаблонном метапрограммировании хорошо. Но оно само создает ряд серьезных проблем. Короче сейчас мы снова пойдем по кругу.
Тут дело даже не столько в шаблонном метапрограммировании, сколько в том, что грамматика является кодом на С++ и взаимодействует с окружением.
Шаблонное метапрограммирование просто добавляет синтаксического сахара, все это можно было бы написать и в ява-подобном синтаксисе без операторов вообще, просто цепочкой вызовов функций — да, выглядеть будет убого, но взаимодействовать с окружением будет.

VD>Ужас! Столько приседаний и все только ради того чтобы это был обязательно С++?

У вас приседаний не меньше — вам и Студия нужна, и куча утилит типа Refactor и architecture explorer...
Ладно, это, видимо, шутка была.

J>>Наверное. Я тебе время компиляции на стареньком gcc 3.4.6 продемонстрировал. Думаю, последний gcc 4.5 будет еще быстрее, учитывая внимание разработчиков именно к скорости перемалывания шаблонов.

VD>Ну, ну.
Что "ну-ну", когда это факт?
http://cpptruths.blogspot.com/2010/03/faster-meta-programs-using-gcc-45-and.html

VD>Полноценный парсер PEG-а Спириту уж точно ни в чем не уступает. Более того алгоритмически они довольно близки.

А вот интересно, можно ли в парсер ПЕГа встроить обратные ссылки, примерно как в этом регэкспе "(.)-\1", чтоб матчить "а-а", но не матчить "a-b"?
В классическом спирите это запишется так:
char value;
//...
anychar_p[ assign_a(value) ] // матчим любой символ, сохраняем его в value
  >> '-'                     // матчим минус
  >> ch_p( ref(value) )      // матчим сохраненный в value символ

Вот результат работы программы:
a-a
-------------------------
Parsing succeeded
-------------------------
a-b
-------------------------
Parsing failed
stopped at: ": b"
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[18]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.07.10 20:38
Оценка:
Здравствуйте, fddima, Вы писали:

F>При чём тут потоковый режим? Лексер не может раскрывать энтити — XmlTextReader это делает.


Я не знаю что ты понимаешь под энтитями, но лексер может разпознать все кроме рекурсивных правил.
Лексер я тут говорю весьма условно. Главное, что это не парсер. Он не позволяет распознать форат. Он только позволяет прочитать отдельные его элементы.

F>>> Дичайших оптимизаций в XmlTextReader тоже нет — абсолютно прозрачная работа с входными данными как они есть, без всяких лишних абстракций. В случае с XML это хорошо работает.

VD>>Там рукописный код написанный не самыми идиотами. Написать что-то более быстрое будет крайне проблематично.
F>Я и говорю — что кардинально быстрее — нет, не напишешь. Все оптимизации которые используются XmlTextReader-ом, для меня лично — очевидны.

Это все равно что ничего не сказать. Лично для меня очевидны все оптимизации которые я могу понять.

F> В основном это: не делать лишних проверок при обработке следующего символа, и уменьшение бранчинга проца.


Это какой-то сумбур. Фактически там рукопашный парсер с морей мелких оптимизаций которые вытекают из знания формата и возможности спрямлять углы вручную. Учитывая что грамматика регулярная, фактически там имеет место ДКА на switch-ах (т.е. реализованный в виде кода, а не на базе таблицы переходов) с ручными оптимизациями. При просто грамотной реализации (а она там грамотная) скорость будет практически оптимальной. При этом, конечно же такой распознаватель не может проверить правильность структуры документа и вообще оперировать структурой. Для этого требуется более высокого порядка — парсер.

F> Всего остального малой кровью не избежать. Плюс ко всему: поведение сильно зависит от настроек и некоторые из оптмизаций доступны только для определенных конфигураций.


Тут я вообще не понимаю о чем идет речь.

ЗЫ

Что касается измерений в статье на которую дана ссылка здесь:
http://rsdn.ru/forum/philosophy/3862525.1.aspx
Автор: z00n
Дата: 01.07.10


Статья несколько странная. В ней говорится об оптимизации комбинаторных парсеров, но по факту предлагается вместо парсящий комбинаторов применять комбинаторы строящие конечные автоматы с последующей их оптимизацией, преобразованием в таблицу переходов и в итоге созданию распознователя использующего эту таблицу.
Тут странно, во-первых, то что по сути меняется тип парсера, но это называется оптимизацией. И во-вторых (самое странное), всем известно что с помощью КА можно распозновать исключительно регулярные грамматики. Тесты используемые в статье распознают регулярную грамматику. По этому оптимизированный сканер автора позволяет распознавать грамматику из теста. По этому же получилось относительно легко использовать XmlTextReader. Однако XmlTextReader оказался еще и в неравных условиях, так как он производит честный лексический разбор ХМЛ-я, в кто время как остальные распознают упрощенную версию достаточную для вычленения нужных данных. Кроме того XmlTextReader корректно работает с юникод-строками, в то время как "оптимизированный комбинаторный парсер" автора работает с ANSI-кодировкой (8-битным символом). Причем его принципиально нельзя научить работать с юникодом, так как это привдет к дикому распуханию таблицы переходов.
Так же автор не упоминает, что по мере усложнения грамматики табличный парсер теряет эффективность просто потому что растет объем таблицы.

Что касается LPEG, то он реализован весьма интересно. Там PEG-грамматика преобразуется в код специальной виртуальной машины с очень простым набором инструкций. После этого исполняется уже программа на этой виртуальной машине.
Скорость которую показывает LPEG на этот тесте впечатляющая, но все же она более чем в двое уступает рукописному парсеру.
Учитывая, что грамматика используемая в тесте является регулярной и очень простой, не трудно предсказать, что по мере роста сложности грамматики LPEG будет все больше и больше проигрывать. В прочем для него можно делать множество оптимизаций. От использования ДКА для парсинга терминальных правил. До использования джит-компиляции для ускорения его работы.

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

В прочем, без алгоритмических оптимизаций для достижения высокой скорости на сложных грамматиках их придется подвергать левой факторизация, а сами грамматики должны быть максимально близки к LL(1). Однако для замены регексам — это и так будет манной небесной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.07.10 20:49
Оценка: +1
Здравствуйте, z00n, Вы писали:

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

Z>Интерпретируемый код не всегда медленнее, например интепретируемый LPEG по скорости не устепает LEX/YACC.

Z>Недавно проводились тесты, где интепретируемый LPEG (с моей подачи) слегка порвал Boost-Spirit:
Z>http://fprog.ru/2010/issue5/dmitry-popov-optimizing-parser-combinators/

Z>
Z>Lua / LPEG (на языке Lua описывается            | 20.2 МБ/с <--
Z>грамматика, а разбор по ней осуществляет        | 
Z>модуль LPEG на Си).                             | 
Z>                                                | 
Z>Оптимизирующие парсер-комбинаторы на OCaml,     | 42.6 МБ/с
Z>включая время на построение графа,              | 
Z>его оптимизацию, построение таблицы и т. д.     | 
Z>                                                | 
Z>Наконец, вариант C# с System.Xml                | 46.0 МБ/с
Z>


Твоя же таблица не подтверждает твоих слов. Рукописный парсер (XmlTextReader) рвет LPEG в 2.6 раз. К тому же XmlTextReader парсит ХМЛ честно, в то время как все остальные разбирают сильно упрощенную грамматику.

Намного лучшие реузультаты у "Оптимизирующие парсер-комбинаторы на OCaml" который по факту тоже в общем-то является практически интерпретатором. Он работает по таблице переходов ДКА который строится на основе комбинаторов. Но и этот вариант медленнее оптимального, компилированного кода. Конечно можно сказать, что он очень незначительно медленнее, но тут надо вспомнить, что XmlTextReader работает с более широким набором символов (UNICODE 16, в то время как окамловский работает с ANSI (8 бит)) и распозноет полную грамматику ХМЛ-я, а не упрощенную грамматику. Так что если их поставить в равные условия, то окамловский парсер будет проигрывать значительно больше (да и LPEG тоже).

Вот здесь
Автор: VladD2
Дата: 06.07.10
, в конце, я высказал еще кое какие мысли по поводу этой статьи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.07.10 21:32
Оценка:
Здравствуйте, jazzer, Вы писали:

VD>>Что-нить на событиях залудить. Для немерлового макроса мы эту задачу решили. Более того, в последствии, при обсуждении следующего поколения макросов было придумано еще более красивое решение. Но оно уже точно реализуемо только в рамках мощной макросистемы (в С++ вряд ли удастся повторить). А вариант с событиями реализовать вполне можно.

J>Можешь кинуть линк, как это сделано на событиях в Немерле сейчас, пожалуйста? Чтоб мне самому не искать.

Полноценного описания пока нет. Но все очень просто. Вот пример парсера простого строчного калькулятора.

Грамматика описывается в виде атрибута (на самом деле это макрос — метаатрибут) уровня класса. Обработчики — это метода имена которых совпадают с именем правила. Например:
[PegGrammar(start,
grammar
{
  ...
  num                   : int = digit spaces;
  ...
  simplExpr             : int = num / parenthesesExpr / unaryMinus / parenthesesExprError / simplExprError;
  ...
})]
public class CalcParser
{    
  private num(digit : NToken, _ : NToken) : int
  {
    int.Parse(digit.GetText())
  }
  ...
  private simplExpr(se : VToken[int]) : int
  {
    se.Value
  }

Параметры должны соотвествовать подправилам правила для которого создается обработчик.
Правила разделенные оператором приоритетного выбора "/" описывают один параметр.
Типы всех правил в таком списке должны совпадать.
Другими видами подправил является циклы и группы например: (...)* или (...).
Есть два типа параметров NToken — описывает распознанный текст и используется для терминалов.
И VToken[T] — описывает значение возвращенное другим правилом (добавляя к нему информацию о месптоположении распознанного участка текста).
Когда макрос генерирует код, он вставляет вызовы обработчиков в те места где заканчивается разбор соответствующего правила.
В принципе ничто не мешает встраивать код прямо по месту (инлайнить).

Более продвинутая модель придумана для следующей версии макросов немерла (но в принципе ее можно использовать и в рамках построителей парсеров). Подробнее о ней можно почитать здесь
Автор: VladD2
Дата: 24.06.10
. Пользуясь случаем еще раз выражаю благодарность товарищу Тролу зеленому за творческие идеи
Автор: Тролль зеленый и толстый
Дата: 23.06.10
.

J>А то, что Немерле макросистема мощная — так с этим, вроде, и не спорит никто.


Ну, почему же? Вот рядом Булат во всю доказывает, что макрос отстой.

VD>>Я помню о чем мы говорим. И пример привел не случайно. В нем тупо генерируются исходники (текст) и компилируются с помощью csc.exe. Тоже самое можно делать любым компилятором С++.

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

Это все заблуждения. Все можно завернуть в синтаксис вида:
auto precompiledParrern = PEG::CompilePattern("образец в формате пег", handler1, ... handlerN);
auto precompiledParrern.Match(); // или Search, Parse и т.п.


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

Еще одним вариантом может быть просто использование LPEG с легким фасадом на С++. LPEG — это С-шная библиотека сделанная для Lua и реализующая динамический компилятор PEG-грамматики в код на специализированной виртуальной машине (написаной на С). Незнаю насколько сложно отделить ее от Lua, но в остальном она очень даже ничего. По тестам здесь она даже немного быстрее Спирита.

J>>>Насчет классического генератора кода — это очень неудобно, поэтому, как ты и сам отметил в корневом сообщении, этим никто не пользуется.

VD>>Согласен. Но можно же все это завернуть в библиотеку которая все автоматизирует.
J>Ну, это ж не Немерле, в котором прямо из компилятора можно внешние программы звать
J>Или ты что-то другое имеешь в виду под библиотекой?

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


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

J>Тут дело даже не столько в шаблонном метапрограммировании, сколько в том, что грамматика является кодом на С++ и взаимодействует с окружением.

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

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


Вот тут действительно уместно сказать о Немерле, так как шаблонное метапрограммирование дейсвительно хреновое средсво для создания сахара, если сравнивать его с полноценными макрами. Уж если есть такое желание заниматься МП, то надо было не использовать побочные эффекты от шаблонов, а встроить в язык полноценный движок синтаксических макросов.


J>>>Наверное. Я тебе время компиляции на стареньком gcc 3.4.6 продемонстрировал. Думаю, последний gcc 4.5 будет еще быстрее, учитывая внимание разработчиков именно к скорости перемалывания шаблонов.

VD>>Ну, ну.
J>Что "ну-ну", когда это факт?
J>http://cpptruths.blogspot.com/2010/03/faster-meta-programs-using-gcc-45-and.html

Но не в сотни же раз? Я скорее поверю в то, что сам Спирит подрихотвали чтобы он меньше тормозил.

VD>>Полноценный парсер PEG-а Спириту уж точно ни в чем не уступает. Более того алгоритмически они довольно близки.

J>А вот интересно, можно ли в парсер ПЕГа встроить обратные ссылки, примерно как в этом регэкспе "(.)-\1", чтоб матчить "а-а", но не матчить "a-b"?

Сам ПЕГ описывает парсеры контекстно свободных языкво. Но в приципе можно сделать и такое расширение. Не думаю, что в них есть смысл. Такие вещи лучше в обработчиках проверять.

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

J>В классическом спирите это запишется так:

J>
J>char value;
J>//...
J>anychar_p[ assign_a(value) ] // матчим любой символ, сохраняем его в value
  >>> '-'                     // матчим минус
  >>> ch_p( ref(value) )      // матчим сохраненный в value символ
J>


Можно легко добавить проверку в обработчике и отвергнуть неверную строку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: PEG vs RegExp
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 06.07.10 13:32
Оценка: -1 :)
Здравствуйте, gandjustas, Вы писали:

G>Ну потому что ты другого не пробовал (снова Блаб). Я вот в 2010 студии открыл для себя architecture explorer, с тех пор вообще поиском не пользуюсь.


Пркольно. Погуглил, посмотрел картинки — похоже на Class Browser из Smalltalk за 1981г.
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[18]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.07.10 13:36
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


G>>Ну потому что ты другого не пробовал (снова Блаб). Я вот в 2010 студии открыл для себя architecture explorer, с тех пор вообще поиском не пользуюсь.


ANS>Пркольно. Погуглил, посмотрел картинки — похоже на Class Browser из Smalltalk за 1981г.


Выделенное повеселило.
Re[22]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.10 20:41
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Потому что регэкспы — это промышленный стандарт уже бог знает сколько десятков лет, и правила вывода в нем есть, всё через те же обратные ссылки, которых в принципе нет в пеге.

J>Причем не просто стандарт, а удобный практический инструмент для своих задач.

Можно совет? Прежде чем бросаться необдуманными заявлениями лучше разобраться в предмете спора и попробовать почитать/послушать умных людей. Вот тебе ссылочнка для затравочки. Там где-то час видео, но уверен, что досмотрев до конца наступит просветление, если конечно упертость не носит клинический характер.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.10 20:48
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>ЩИТО? Да полно ведь реализаций уже:

DM>http://en.wikipedia.org/wiki/Comparison_of_parser_generators#Parsing_Expression_Grammars

Хм страничка называется "Comparison of parser generators". Тебе не кажется, что я говорил о другом?
Попробуй еще раз прочесть мои слова, но вдумчиво.

VD>> Но выше крыши не прыгнишь. Плюс алгоритм там самый что ни на есть дубовый (пербор с откатами) и тут уже ничего не оптимизируешь.


DM>Элементарно PEG оптимизируется:

DM>http://fprog.ru/2010/issue5/dmitry-popov-optimizing-parser-combinators/
DM>И быстрые автоматы из комбинаторов строить можно.

Какое отношение конечные автоматы имеют к PEG? Ты в курсе, что конечные автоматы могут описывать исключительно регулярные грамматик. Или тебе кажется, что возможности PEG-а ими ограничено?

DM>А, вижу ссылку уже дали.


Единственная реально-работающая ссылка — это ссылка на LPEG. С некоторой натяжкой можно еще привести ссылку на буст.Спирит. Остальное — пальцем в небо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.10 22:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я незнаю что такое "sed" и "PCRE" но я точно знаю что чудес не бывает. Если используемый алгоритм более эффективен и он в добавок использует скомпилированный код, а не интерпретацию, то он не может быть сравним по производительности с интерпретируемым и менее эффективным алгоритмом.


В этом видео сам автор LPEG-а подтверждает мои слова, говоря:
1) что прототип джит-компилятора ускоряет работу LPEG в 3 раза на всех без исключения паттернах.
2) говорит о том, что на более сложных грамматиках LPEG все больше и больше отстает от Yacc/Lex и подтверждает, что так и должно быть.

В общем, хвала и честь этим ребятам за то что они сделали весьма эффективную реализацию PEG-парсера, но чудес таки не бывает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.07.10 22:26
Оценка:
Здравствуйте, mefrill, Вы писали:

M>Не хочу тратить время и искать очевидные ошибки в тестировании. Очевидно, что рекурсивный парсер с откатами не может быть быстрее, чему LR(1)-автомат.


А я таки потратил и хоть и поверхностно но разобрался. Во-первых он таки проигрывает яку. Во-вторых, чем сложнее грамматика тем проигрыш больше.

Об этом говорят сами авторы (см. http://vimeo.com/1485123).

В тестах где LPEG былизок к Яку или даже несколько его превосходит разбирается очень простая грамматика (примитивная). Посему откатов просто нет. Самый сложный пример тестируемый ими — это "очень простой язык программирования". В этом языке так же нет конструкций которые могли бы привести к серьезному бэктрэкингу. Однако на этом примере ЛПЕГ сливает Яку около 30%. В прочем, это очень хороший показатель. Так что думаю в тестах есть еще какие-то темные стороны . Я бы поверил в двух-трех кратный проигрыш.

Но в общем и целом ребята писавшие LPEG молодцы. Они не применяют прямую интепретацию. Вместо этого они создали специализированный (очень упрощенный) язык (байткод) и написали на С эффетивную виртуальную машину для него. Хвастались даже что у них есть прототип джит-компилятора который быстрее оригинала в 3 раза. Если это правда, то возможно, что на некотором классе грамматик это решение и правда будет быстрее Яка. Только тут уже ничего удивительного не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 07.07.10 13:00
Оценка:
Здравствуйте, VladD2, Вы писали:

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


J>>Потому что регэкспы — это промышленный стандарт уже бог знает сколько десятков лет, и правила вывода в нем есть, всё через те же обратные ссылки, которых в принципе нет в пеге.

J>>Причем не просто стандарт, а удобный практический инструмент для своих задач.

VD>Можно совет? Прежде чем бросаться необдуманными заявлениями лучше разобраться в предмете спора и попробовать почитать/послушать умных людей.

Так я и послушал умного человека gandjustas, это его слова были, вообще-то, не мои:

G>Стандартного синтаксиса вывода нет, а придумывать не хочу.

Так что вы уж с ним вдвоем определитесь, как умные люди — есть стандартный синтаксис или нет.

VD>Вот тебе ссылочнка для затравочки. Там где-то час видео, но уверен, что досмотрев до конца


Ты сам-то видео досмотрел до конца? Мужик там открытым текстом говорит, что ниша LPEG лежит _между_ регэкспами и полноценными парсерами (69-я минута).

VD>наступит просветление, если конечно упертость не носит клинический характер.

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

А насчет необдуманных заявлений: регэкспы — это не промышленный стандарт уже бог знает сколько десятков лет? Сравним с возрастом и распространенностью LPEG, который датируется 2008 годом и которого до сих пор даже первая версия не вышла? А регэкспы, между тем, реализованы практически везде, включая Java, .Net и Python. Не говоря уже о С/С++ и перле. Причем реализованы со всеми заглядываниями вперед-назад и обратными ссылками. Правда, некоторые умные люди об этом просто не знают.

А как насчет ПЕГ-ориентированного инструментария? С регэкспами у меня есть куча инструментов командной строки, которые я могу использовать: grep, sed, awk, perl. Так что если мне приспичит найти нечто _достаточно простое_ в текстовом файле, у меня это займет пару минут, и на написание регэкспа будет достаточно усилия спинного мозга. Причем _простой_ процессинг (я имею в виду, обработку извлеченных данных, а не просто найти/заменить, что и sed может сделать) можно выполнить в том же перле, в одну строчку, прямо в командной строке. Далее, практически все вменяемые текстовые редакторы и прочие программы, предоставляющие доступ к текстовым данным, предлагают ту или иную форму поиска по регэкспам (даже MS SQL Server: http://msdn.microsoft.com/en-us/magazine/cc163473.aspx).
Что мне предлагает ПЕГ в _этом_ отношении?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[19]: PEG vs RegExp
От: mefrill Россия  
Дата: 07.07.10 13:52
Оценка: +3
Здравствуйте, VladD2, Вы писали:

VD>А я таки потратил и хоть и поверхностно но разобрался. Во-первых он таки проигрывает яку. Во-вторых, чем сложнее грамматика тем проигрыш больше.


Вот я и говорю, для полноценных тестов необходимо разработать грамматики с разлиными характеристиками: лесистостью, ветвистостью, длинной правой части и т.п. Выделить несколько групп таких грамматик по сложности и посмотреть, как будет меняться скорость разбора от сложности грамматики. Результатом такого теста будет график изменения скорости в зависимости от описанных характеристик грамматики. Без таких вещей это не тесты.
Re[24]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.07.10 14:04
Оценка:
Здравствуйте, jazzer, Вы писали:

J>А насчет необдуманных заявлений: регэкспы — это не промышленный стандарт уже бог знает сколько десятков лет? Сравним с возрастом и распространенностью LPEG, который датируется 2008 годом и которого до сих пор даже первая версия не вышла? А регэкспы, между тем, реализованы практически везде, включая Java, .Net и Python. Не говоря уже о С/С++ и перле. Причем реализованы со всеми заглядываниями вперед-назад и обратными ссылками. Правда, некоторые умные люди об этом просто не знают.


Ты все еще не понимаешь чего ты не понимаешь

Давай сначала.
Регулярные выражения были созданы для описания Регулярных Грамматик.
Я уверен что ссылку ты не прочитаешь, поэтому приведу определение здесь:

Регулярная грамматика может быть задана набором правил как левая или правая регулярная грамматика.

правая регулярная грамматика — все правила могут быть в одной из следующих форм:
A → a
A → aB
A → ε

левая регулярная грамматика — все правила могут быть в одной из следующих форм:
A → a
A → Ba
A → ε

где


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


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

От этого основные преимущества регулярных грамматик:
1)Парсер никогда не зацикливается (автомат конечен).
2)Парсер работает за линейное время.

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

НО:
1)На практике преобразования НДКА в ДКА не всегда возможно при наличии вывода парсера (возврата результата разбора), поэтому преимущество №2 теряется, разбор в некоторых случаях делается за экспонециальное время (ибо используются откаты).
2)С другой стороны регулярные грамматики описывают довольно узкий класс языков. Например невозможно описать регулярной грамматикой парность скобок. Поэтому были придуманы расширения типа "обратных ссылок", которые уже позволяют парсить языки шире чем регулярные, но тогда теряется преимущество №1.
3)Я не нашел в сети упоминаний какой мощности языки парсят регулярные выражения с обратными ссылками, но есть подозрения что это не все КС-языки.

PEG, в отличие от regexp, не обладает такими врожденными и унаследованными недостатками. PEG может парсить все КС-языки.

Преимущества современных regexp в том, что для них давно устоявшийся (и даже стандартизованый) синтаксис и кучи инструментов. Но этот же синтаксис является недостатком, потому что в нем невозможно описывать нетривиальный вывод парсера. Хотя для описания КС языков ситуация еще хуже, стандартного синтаксиса нет вообще, а вывод в парсерах зачастую описывается на самом языке программирования, что превращает описание парсера в нечитаемую хрень.

Vlad предлагает описывать парсер с помощью макросов в nemerle, а вывод на самом nemelre. Также Vlad предлагает этап "компиляции" парсера, который присуствут и в регэкспах, и в любом другом парсере вынести в этап компиляции программы (ибо 99% грамматик фиксированы на этапе компиляции программ), что позволит ускорить многие программы, обрабатывающие текст).

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

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

ЗЫ. Тебе нечего беспокоиться. Пока что это будет только в Nemerle, а в других языках будут максимум парсер-комбинаторы (хотя в хаскеле они удачно вытеснили другие методы разбора). А уж из перла регулярные выражения вообще никда не пропадут, они скорее эволюционируют во что-то peg-подобное.
Re[25]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 07.07.10 15:10
Оценка:
Здравствуйте, gandjustas, Вы писали:

Все формальное сравнение PEG с регэкспами, которые ты написал, я скипнул, потому что полностью с ним согласен (и не спорил никогда).

G>Преимущества современных regexp в том, что для них давно устоявшийся (и даже стандартизованый) синтаксис и кучи инструментов. Но этот же синтаксис является недостатком, потому что в нем невозможно описывать нетривиальный вывод парсера.


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

G>Хотя для описания КС языков ситуация еще хуже, стандартного синтаксиса нет вообще, а вывод в парсерах зачастую описывается на самом языке программирования, что превращает описание парсера в нечитаемую хрень.


Угу. Хотя спирит2, имхо, достаточно хороший пример читабельности в этом смысле.

G>Vlad предлагает описывать парсер с помощью макросов в nemerle, а вывод на самом nemelre. Также Vlad предлагает этап "компиляции" парсера, который присуствут и в регэкспах, и в любом другом парсере вынести в этап компиляции программы (ибо 99% грамматик фиксированы на этапе компиляции программ), что позволит ускорить многие программы, обрабатывающие текст).


Я только за. Где я хоть слово против сказал

G>В итоге в программах, будут использоваться regex там где выполняются основные их преимущества, описанные выше (например wildcards при поиске в тексте) , а для всего остального будет PEG.


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

G>Наличие кучи инструментов вроде sed, awk и тому подобного для программиста, который пишет программу, нуждающуюся в разборе текста, не являет решающим. Хотя оно являются решающим для админов и других пользователей, которые не занимают разработкой программ.


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

G>ЗЫ. Тебе нечего беспокоиться. Пока что это будет только в Nemerle, а в других языках будут максимум парсер-комбинаторы (хотя в хаскеле они удачно вытеснили другие методы разбора). А уж из перла регулярные выражения вообще никда не пропадут, они скорее эволюционируют во что-то peg-подобное.


Уже эволюционировали. Как ты правильно заметил раньше, нынешние регэкспы — это не классические регулярные выражения.
В принципе, все, что я говорил о регэкспах раньше, относится не к тру-регэкспам, а к этим продвинутым, которые везде поддерживаются и широко используются и которые просто сохранили за собой название регэкспов (мне вот практически не встречались люди, которые, говоря "регулярные выражения", при этом имели бы в виду только тру-регэкспы).
Плюс можешь посмотреть сюда: http://en.wikipedia.org/wiki/Perl_6_rules
Короткая цитата оттуда:

A few of the most powerful additions include:

* The ability to reference rules using <rulename> to build up entire grammars.
* A handful of commit operators that allow the programmer to control backtracking during matching.


Итого: вроде спорить больше не о чем.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: PEG vs RegExp
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 07.07.10 17:13
Оценка:
Здравствуйте, VladD2, Вы писали:

DM>>ЩИТО? Да полно ведь реализаций уже:

DM>>http://en.wikipedia.org/wiki/Comparison_of_parser_generators#Parsing_Expression_Grammars

VD>Хм страничка называется "Comparison of parser generators". Тебе не кажется, что я говорил о другом?

VD>Попробуй еще раз прочесть мои слова, но вдумчиво.

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

VD>>> Но выше крыши не прыгнишь. Плюс алгоритм там самый что ни на есть дубовый (пербор с откатами) и тут уже ничего не оптимизируешь.


DM>>Элементарно PEG оптимизируется:

DM>>http://fprog.ru/2010/issue5/dmitry-popov-optimizing-parser-combinators/

VD>Какое отношение конечные автоматы имеют к PEG? Ты в курсе, что конечные автоматы могут описывать исключительно регулярные грамматик. Или тебе кажется, что возможности PEG-а ими ограничено?


Попробуй еще раз прочитать статью, но вдумчиво. Там показан простой способ оптимизации классических парсер-комбинаторов (класса не ниже PEG) через мемоизацию и ленивые вычисления. Конечные автоматы тут ни при чем.
Re[24]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.10 17:15
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Так я и послушал умного человека gandjustas, это его слова были, вообще-то, не мои:

J>

G>>Стандартного синтаксиса вывода нет, а придумывать не хочу.


Я вашу беседу не осилил. А без контекста понять что означает "синтаксиса вывода" мне тяжело.

PEG — это как раз нотация. Стандарта на нее нет, но она стала стандартом дефакто.

VD>>Вот тебе ссылочнка для затравочки. Там где-то час видео, но уверен, что досмотрев до конца


J>Ты сам-то видео досмотрел до конца?


Да.

J>Мужик там открытым текстом говорит, что ниша LPEG лежит _между_ регэкспами и полноценными парсерами (69-я минута).


LPEG создавался как замена регексам, так что это не удивительно. Ну, а парсером он является просто потому что он PEG, так как нет ограничения на использование регулярной грамматики.

Но я что-то вообще не пойму к чему это замечание.

VD>>наступит просветление, если конечно упертость не носит клинический характер.

J>И какого же характера просветление у меня должно было наступить? И какое просветление наступило у тебя, раз уж ты так восторженно об этом говоришь?

Ты свои слова то помнишь? Мне кажется, что после просмотра этого видео логично было бы во многом их пересмотреть.

J>Я не увидел и не услышал абсолютно ничего такого, чего я не знал раньше, за исключением собственно LPEG — за это спасибо, шариться по их сайту было бы лень. Теперь буду знать, что на Луа есть такая вот хорошая библиотека. Если буду писать на Луа — обязательно заюзаю.


Библиотека-то сишная. Так что на С++ ее можно спокойно использовать (создав соответствующую обертку).

J>А насчет необдуманных заявлений: регэкспы — это не промышленный стандарт уже бог знает сколько десятков лет?


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

J>Сравним с возрастом и распространенностью LPEG, который датируется 2008 годом и которого до сих пор даже первая версия не вышла? А регэкспы, между тем, реализованы практически везде, включая Java, .Net и Python.


Теперь встает вопрос внимательно ли ты читал мое тематическое сообщение?

J> Не говоря уже о С/С++ и перле. Причем реализованы со всеми заглядываниями вперед-назад и обратными ссылками. Правда, некоторые умные люди об этом просто не знают.


Даже те кто знают не всегда могут применить все это дело по массе причин которые отлично описаны в видео.

J>А как насчет ПЕГ-ориентированного инструментария? С регэкспами у меня есть куча инструментов командной строки, которые я могу использовать: grep, sed, awk, perl.


А они нужны? В отличии от регексов ПЕГ позволяет произвести декомпозицию сложного паттерна на множество простых и отлаживать каждый из них по отдельности.

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

J>Так что если мне приспичит найти нечто _достаточно простое_ в текстовом файле, у меня это займет пару минут, и на написание регэкспа будет достаточно усилия спинного мозга.


Как человек использовавший оба варианта заверяю, что это не соответствует действительности. ПЕГ пишется и отлаживается в разы проще. Если бы ты внимательно смотрел видио, то заметил бы почему это так происходит.

J>Причем _простой_ процессинг (я имею в виду, обработку извлеченных данных, а не просто найти/заменить, что и sed может сделать) можно выполнить в том же перле, в одну строчку,


Дык, если бы это было не так, то не ясно зачем тогда вообще был бы нужен Перл. Перл и регексы близнецы-браться. Но тем не менее LPEG удобнее, предсказуемее. К тому же в Перлв 6 ПЕГ встроен в Перл. Так что даже говорить особо не о чем. Теперь Перл == ПЕГ, а не прегекспы.

J>Далее, практически все вменяемые текстовые редакторы и прочие программы, предоставляющие доступ к текстовым данным, предлагают ту или иную форму поиска по регэкспам (даже MS SQL Server: http://msdn.microsoft.com/en-us/magazine/cc163473.aspx).

J>Что мне предлагает ПЕГ в _этом_ отношении?

Все тоже самое но намного удобнее. Я очень жалею, что в той же VS не поддерживается ПЕГ. Иногда нужно найти некоторую синтаксическую конструкцию, а на регексах (доступных в VS) это сделать невозможно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.10 17:29
Оценка: :)
Здравствуйте, D. Mon, Вы писали:

DM>Твои слова определенно можно понять как жалобу на остутствие реализаций PEG в мэйнстримных языках и попытку выдать реализацию ее в Немерле за большое достижение.


Просто какие-то проблемы с русским письменным . Точнее даже какая-то телепатия на марше.

Можно показать где в тексте моего сообщения упоминается Nemerle?
У некоторых отдельных личностей не РСДН просто какие-то телепатические галлюцинации .

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

DM>Я лишь показал, что жалоба мимо кассы и реализаций уже немало.


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

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

VD>>>> Но выше крыши не прыгнишь. Плюс алгоритм там самый что ни на есть дубовый (пербор с откатами) и тут уже ничего не оптимизируешь.


DM>>>Элементарно PEG оптимизируется:

DM>>>http://fprog.ru/2010/issue5/dmitry-popov-optimizing-parser-combinators/

VD>>Какое отношение конечные автоматы имеют к PEG? Ты в курсе, что конечные автоматы могут описывать исключительно регулярные грамматик. Или тебе кажется, что возможности PEG-а ими ограничено?


DM>Попробуй еще раз прочитать статью, но вдумчиво.


В отличии от тебя, я как раз читал вдумчиво.

DM>Там показан простой способ оптимизации классических парсер-комбинаторов (класса не ниже PEG) через мемоизацию и ленивые вычисления. Конечные автоматы тут ни при чем.


Ты увидел то чего там нет в помине. Нет там никакой оптимизации классический парсер-комбинаторов. Вместо "классических" парсер-комбинаторов там предлагается использовать "автоматные парсер-комбинаторов" (назовем их так), которые с "классическими" несовместимы, так как возвращают данные для построения конечного автомата, а не вычисляющую функцию. Об это говорится и в обсуждении (в ЖЖ). Фактически в этой статье три слабо связанных между собой части: 1) описание классических парсер-комбинаторов, 2) рассуждения о Паркате, 3) описание автоматных комбинаторов. Связь между п.1 и п.3 заключается только в том, что и то, и то реализовано с помощью комбинирования функций высшего порядка.

Так что прежде читай вдумчиво. Тогда подобного рода замечаний просто не возникнет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: PEG vs RegExp
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 07.07.10 18:10
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>В отличии от тебя, я как раз читал вдумчиво.


Жжошь!

DM>>Там показан простой способ оптимизации классических парсер-комбинаторов (класса не ниже PEG) через мемоизацию и ленивые вычисления. Конечные автоматы тут ни при чем.


VD>Ты увидел то чего там нет в помине. Нет там никакой оптимизации классический парсер-комбинаторов. Вместо "классических" парсер-комбинаторов там предлагается использовать "автоматные парсер-комбинаторов" (назовем их так), которые с "классическими" несовместимы, так как возвращают данные для построения конечного автомата, а не вычисляющую функцию. Об это говорится и в обсуждении (в ЖЖ). Фактически в этой статье три слабо связанных между собой части: 1) описание классических парсер-комбинаторов, 2) рассуждения о Паркате, 3) описание автоматных комбинаторов. Связь между п.1 и п.3 заключается только в том, что и то, и то реализовано с помощью комбинирования функций высшего порядка.


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

VD>Так что прежде читай вдумчиво. Тогда подобного рода замечаний просто не возникнет.


Я ту статью не только читал, но и писал, между прочим. Ты говоришь с ее автором.

Что касается "которые с "классическими" несовместимы, так как возвращают данные для построения конечного автомата, а не вычисляющую функцию", то позволь напомнить, что самая известные парсер-комбинаторы — Parsec — тоже возвращают данные, которые потом запускаются на интерпретацию отдельной функцией.
Re[6]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.10 18:38
Оценка:
Здравствуйте, D. Mon, Вы писали:

VD>>В отличии от тебя, я как раз читал вдумчиво.


DM>Жжошь!


ОФтоп 1: Здесь за "падонковщину" банят.
Офтоп 2: В зеркало чаще смотри.

DM>Попробуй повернуть монитор, а то мои слова в слепое пятно глаза попали.


Чуть не сломал, но ничего не изменилось.

DM>Еще раз: способ оптимизации PEG (точнее, классических комбинаторов, но они PEG реализуют и кое-что покруче тоже) заключается в мемоизации.


Какая-то сумбурная фраза.

Итак по порядку:
1. PEG — это нотация. Ее оптимизировать нельзя. Оптимизировать можно конвертерные алгоритмы его парсинга.
2. "классические" комбинаторные парсеры имеют мало отношения к PEG-у, зато являются реализацией классического алгоритма нисходящего парсинга с откатами (TDPL with backtracking).
3. Мемоизация в чистом виде не является оптимизацией. Она обеспечивает теоретическое константное время парсинга, но при этом требует линейного увеличения объема памяти (количество правил * на количество сиволов во входной строке) и очень высокой константой (о чем говорится в видео).
4. В упамянутой статье лишь вскользь упоминается использование мемоизации (алгоритм Пакрат), а остновная ее часть посвящена комбинаторам-построителям ДКА.

Так что по всем пунктам мимо. И ты осмелеваешся утверждать, что читал внимательно?

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


Только пакрат и есть. Внятных опсаний частичной мемоязации я еще не видел. Есть только Ратс, который что-то там делает, но и там нет формальных выкладок.

Опять же в статье про это практически ничего не говорится. И воообще статья крайне сумбурная. Ей не хватает добротной редактуры и рецензирования.

DM>Третий пункт статьи (про КА) независим от первых двух и не является полноценным способом их оптимизации.


Но именно о нем и говорит автор когда говорит об оптимизациях. Еще раз повторюсь... про мемоизацию там только упоминается вскользь. Даже примеров кода не приводится.

VD>>Так что прежде читай вдумчиво. Тогда подобного рода замечаний просто не возникнет.


DM>Я ту статью не только читал, но и писал, между прочим. Ты говоришь с ее автором.


Замечательно. Это только подтверждает правило — "худший читатель — это автор". Тогда прими как данность, что если ты пытался написать о мемоизации, то у тебя получилось не очень хорошо.

Собственно раз уж ты автор, то у меня к тебе есть встречное предложение.
Прелдагаю сделать версию 2.0 этой статьи в которой устранить недостатки. Как минимум:
1. Четко объяснить к чему там комбинаторы строящие ДКА.
2. Четко указать, что они сами по себе могут парсить только регулярные грамматик.
3. Обяснить (а лучше пказать) как комбинаторы коненых автоматов можно использовать для парсинга нерегулярных грамматик.
4. Расширить раздел про мемоизацию добавив в него код демонстриующий этот подход и тесты демонстрирующие выигрышь/проигрышь от полной и частичной мемоизации.
5. Отделить "мух от котлет" (нотации вроде PEG от реализаоций вроде комбинатроных парсеров нисходящего спуска с откатами).

Готов помочь в этом деле при условии, что статья в последсвии будет опубликована на РСДН.

DM>Что касается "которые с "классическими" несовместимы, так как возвращают данные для построения конечного автомата, а не вычисляющую функцию", то позволь напомнить, что самая известные парсер-комбинаторы — Parsec — тоже возвращают данные, которые потом запускаются на интерпретацию отдельной функцией.


Я могу ошибасться (не хасклист), но Парсек вроде бы возвращал функции парсинга. И в статье как раз приводятся примеры этого (хотя и на Окамле).

ЗЫ

В общем, не обижася, но в исходном виде статья сумбурная. Она создает больше вопросом нежели снимает.
Если ты можешь "конструктивно принимать критки", то предлагаю создать вторую версию в которой устранить эти недостатки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.07.10 22:39
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>Не только те основные преимущества, которые ты упомянул для "истинных регэкспов" (т.е. линейное время и т.д.), но и удобство перловых регэкспов, с их заглядываниями и обратными ссылками. Конкретно обратные ссылки Пег предоставить не может, и это, имхо, снижает ценность ПЕГа для использования в качестве поисковой строки от юзера.

Конкретно обратные ссылки — костыль, чтобы расширить класс языков, которые умеет парсить regex. Они сильно снижают читабельность.

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

J>И вот тут регэкспы (вкупе с грепами, седами и перлами) рулят, по моему скромному опыту, причем рулят просто по критерию простоты и скорости достижения результата — написал за минуту, отладил за три, получил нужную информацию и все, твоя команда максимум в какой-нть bash_history останется.
Ну это только твой опыт, кроме перловых программистов наверное мало кто так массово пользуется рекэкспами.

J>Итого: вроде спорить больше не о чем.

Ага, видимо ты ошибаешься в оценке сложности и применимости регэкспов из-за своего опыта.
Re[7]: PEG vs RegExp
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 08.07.10 02:51
Оценка: 1 (1)
Здравствуйте, VladD2, Вы писали:

DM>>Еще раз: способ оптимизации PEG (точнее, классических комбинаторов, но они PEG реализуют и кое-что покруче тоже) заключается в мемоизации.


VD>Какая-то сумбурная фраза.


VD>Итак по порядку:

VD>1. PEG — это нотация. Ее оптимизировать нельзя. Оптимизировать можно конвертерные алгоритмы его парсинга.
VD>2. "классические" комбинаторные парсеры имеют мало отношения к PEG-у, зато являются реализацией классического алгоритма нисходящего парсинга с откатами (TDPL with backtracking).

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

VD>3. Мемоизация в чистом виде не является оптимизацией. Она обеспечивает теоретическое константное время парсинга, но при этом требует линейного увеличения объема памяти (количество правил * на количество сиволов во входной строке) и очень высокой константой (о чем говорится в видео).


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

VD>4. В упамянутой статье лишь вскользь упоминается использование мемоизации (алгоритм Пакрат), а остновная ее часть посвящена комбинаторам-построителям ДКА.


Оно не вскользь упоминается, а подробно показано с полными исходниками. Там есть вся реализация, она очень проста. О чем я здесь и толкую.

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


VD>Только пакрат и есть. Внятных опсаний частичной мемоязации я еще не видел.


Нет, не только пакрат. В статье она описана.

VD> И воообще статья крайне сумбурная. Ей не хватает добротной редактуры и рецензирования.


Да, согласен. Рецензентов было несколько, но до идеала все равно далеко.

DM>>Третий пункт статьи (про КА) независим от первых двух и не является полноценным способом их оптимизации.


VD>Но именно о нем и говорит автор когда говорит об оптимизациях.


Вовсе нет.

VD>Еще раз повторюсь... про мемоизацию там только упоминается вскользь. Даже примеров кода не приводится.


Там приведен работающий конкретный пример. Ты, видимо, ждал десятки килобайт кода? Так нет, нескольких строк окамла достаточно.

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


Спасибо.

VD>Прелдагаю сделать версию 2.0 этой статьи в которой устранить недостатки.


Это уже была 2.0, первая версия была год назад в ЖЖ, там никто даже не заметил грубой ошибки в алгоритме (отсутствие откатов), которая была исправлена в 2.0. Можно сделать версию 3.0, но что с ней потом делать?

VD>1. Четко объяснить к чему там комбинаторы строящие ДКА.

VD>2. Четко указать, что они сами по себе могут парсить только регулярные грамматик.

Этот вопрос еще требует изучения. Совершенно не факт, что такими грамматиками их возможности ограничены. Напомню, что там магазинный автомат (со стеком), а не простой ДКА.

VD>3. Обяснить (а лучше пказать) как комбинаторы коненых автоматов можно использовать для парсинга нерегулярных грамматик.

VD>4. Расширить раздел про мемоизацию добавив в него код демонстриующий этот подход и тесты демонстрирующие выигрышь/проигрышь от полной и частичной мемоизации.

Имеющий глаза да увидит. Код там есть.

VD>Готов помочь в этом деле при условии, что статья в последсвии будет опубликована на РСДН.


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

DM>>Что касается "которые с "классическими" несовместимы, так как возвращают данные для построения конечного автомата, а не вычисляющую функцию", то позволь напомнить, что самая известные парсер-комбинаторы — Parsec — тоже возвращают данные, которые потом запускаются на интерпретацию отдельной функцией.


VD>Я могу ошибасться (не хасклист), но Парсек вроде бы возвращал функции парсинга. И в статье как раз приводятся примеры этого (хотя и на Окамле).


Ошибаешься. По крайней мере второй и третий парсек, с которыми я имел дело. Примеры на окамле — да, возвращают функции.
Re[27]: PEG vs RegExp
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 08.07.10 08:12
Оценка:
Здравствуйте, gandjustas, Вы писали:

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

J>>И вот тут регэкспы (вкупе с грепами, седами и перлами) рулят, по моему скромному опыту, причем рулят просто по критерию простоты и скорости достижения результата — написал за минуту, отладил за три, получил нужную информацию и все, твоя команда максимум в какой-нть bash_history останется.
G>Ну это только твой опыт, кроме перловых программистов наверное мало кто так массово пользуется рекэкспами.

Интересно. Может дело в том, что у тех, кто не пользуется регэкспами просто нет нормальных инструментов? Скажем, если опросить работающих под никсами и под виндами — не окажется ли, что с регэкспами значительно меньше работают под виндами, а под никсами их используют более 50% (цифра от балды). Тогда окажется, что дело не в том, перловый программист или нет. Я вот не перловый, но awk/sed и тем более grep пользую постоянно.
Re[28]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.07.10 08:28
Оценка:
Здравствуйте, lomeo, Вы писали:

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


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

J>>>И вот тут регэкспы (вкупе с грепами, седами и перлами) рулят, по моему скромному опыту, причем рулят просто по критерию простоты и скорости достижения результата — написал за минуту, отладил за три, получил нужную информацию и все, твоя команда максимум в какой-нть bash_history останется.
G>>Ну это только твой опыт, кроме перловых программистов наверное мало кто так массово пользуется рекэкспами.

L>Интересно. Может дело в том, что у тех, кто не пользуется регэкспами просто нет нормальных инструментов? Скажем, если опросить работающих под никсами и под виндами — не окажется ли, что с регэкспами значительно меньше работают под виндами, а под никсами их используют более 50% (цифра от балды).

Возможно, в винде банально command line меньше юзают, а в IDE не сильно нужны regexp_ы.

L>Тогда окажется, что дело не в том, перловый программист или нет. Я вот не перловый, но awk/sed и тем более grep пользую постоянно.

А что ты делаешь с их помощью?
Re[8]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.10 14:12
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Эта нотация задает определенный класс грамматик


Естественно.

DM>и довольно однозначно задает алгоритм разбора.


А вот это не так.

DM>Все базовые элементы PEG (последовательность, альтернатива, повторы, опциональность, предикаты) элементарно непосредственно реализуются парсер-комбинаторами.


Это вообще что-то не очень осмысленное. Комбинаторами можно многое решать. В том числе и строить парсеры использующие нисходящий спуск. Более того в отличии от ПЕГ-а где можно описать ограниченный бэктрекинг (только в рамках чайса или цикла "*"). А парсер-комбинаторы в принципе могут бэктрэчится как угодно (даже с использованием ислкючений). Да и вообще они могут вытворять любые нестандартные расширения. Например, парсить контекстно-зависимые грамматики или в какой-то момент тупо сменить алгоритм на те же конечные автоматы. В общем, код есть код. Называть это алгоритмом я бы не стал. Способ — да, но не алгоритм.

Так что сказать что что-то "реализуются парсер-комбинаторами" — все равно что ничего не сказать.

DM> Но не только они — на комбинаторах можно и контекстно-зависимые языки разбирать.


Вот-вот. А можно вместо нисходящего алгоритма использовать какой-то дургой.

VD>>3. Мемоизация в чистом виде не является оптимизацией. Она обеспечивает теоретическое константное время парсинга, но при этом требует линейного увеличения объема памяти (количество правил * на количество сиволов во входной строке) и очень высокой константой (о чем говорится в видео).


DM>Мемоизация, как она описана в статье, является оптимизацией,


Ну, то что опсано в статье это вообще еще то извращение. Преобразовывать перед парсингом исходную строку в список состоящий из символов и набора ленивых ссылок — это еще то извращение.
Она конечно что-то ускоряет, но далеко не так как это требуется для реального применения.
Плюс все зависит от грамматики. Те же выраженя можно парсить со скоростью звука без мемоизации. В тестах макроса Nemerle.Peg вот такая грамматика:
    any                   = ['\u0000'..'\uFFFF'];
    digit                 = ['0'..'9']+;
    spaces                = ' '*;
    
    num                   : int = digit spaces;
    unaryMinus            : int = '-' spaces simplExpr;
    parenthesesExpr       : int = '(' spaces sumOrSub ')' spaces;
    parenthesesExprError  : int = '(' spaces sumOrSub (any / !any);
    simplExpr             : int = num / parenthesesExpr / unaryMinus / parenthesesExprError / simplExprError;
    simplExprError        : int = any;
    inputError            : int = any;
    mulOrDiv              : int = simplExpr (('*' / '/') spaces simplExpr)*;
    sumOrSub              : int = mulOrDiv  (('+' / '-') spaces mulOrDiv )*;
    mainRule              : int = sumOrSub inputError?;
    start                 : int = spaces mainRule !any;

Парсится за вполне приемлемое время. Вот результаты тестов:
expression is:
10    +2 - 3- 4 *4 / 2/   2  + (2+6)/2  +(-1)
text length is:45
Text length: 45 Parse took 00:00:00.0704780
Text length: 45 Parse took 00:00:00.0000528
Text length: 45 Parse took 00:00:00.0000300
Text length: 197 Parse took 00:00:00.0001016
Text length: 805 Parse took 00:00:00.0004012
Text length: 3237 Parse took 00:00:00.0016315
Text length: 12965 Parse took 00:00:00.0095427
Text length: 51877 Parse took 00:00:00.0265185
Text length: 207525 Parse took 00:00:00.1040251

Большая по размеру строка формируется путем четырехкратной канкатинации самой себя с добавлением разделительных операторов:
text = $"($text) + ($text) - ($text) + ($text)";


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

DM>т.к. реально ускоряет разбор сложных грамматик на порядки (у меня есть живой пример).


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

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

DM>Константного времени парсинга не бывает (линейное время это не константное).


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

DM>Оно не вскользь упоминается, а подробно показано с полными исходниками. Там есть вся реализация, она очень проста. О чем я здесь и толкую.


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

VD>>Только пакрат и есть. Внятных описаний частичной мемоязации я еще не видел.


DM>Нет, не только пакрат. В статье она описана.


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

DM>Да, согласен. Рецензентов было несколько, но до идеала все равно далеко.


DM>>>Третий пункт статьи (про КА) независим от первых двух и не является полноценным способом их оптимизации.


VD>>Но именно о нем и говорит автор когда говорит об оптимизациях.


DM>Вовсе нет.


Я тебе говорю как читатель. Такое создается впечатление. Может быть это и не было запланировано, но получилось именно так. Погляди обсуждение в ЖЖ. Там тоже многих были поставлены в тупик. Уверен, что причина была та же.

VD>>Еще раз повторюсь... про мемоизацию там только упоминается вскользь. Даже примеров кода не приводится.


DM>Там приведен работающий конкретный пример. Ты, видимо, ждал десятки килобайт кода? Так нет, нескольких строк окамла достаточно.


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

Потом, подумай сам. Как людям реагировать на статью если в ней даже заголовки выглядят так:
2 Классические парсер-комбинаторы
3 Классические комбинаторы и Packrat
4 Оптимизирующие комбинаторы

К тому же четвертый раздел составляет половину статьи по объему. Вывод получается только один. Автор рассматривает генерацию КА как самый лучший способ оптимизации комбинаторных парсеров. При этом возникает масса вопросов:
1. Почему вообще рассматривается более ограниченное решение (ведь КА не позволяют парсить не регулярные грамматики).
2. Почему не рассматривается вопрос обхода ограничения КА. Например, можно было бы попробовать комбинировать классический комбинаторный подход с генерацией ДКА для регулярных частей грамматики.
3. Каковы результаты применения мемоизации?

DM>Это уже была 2.0, первая версия была год назад в ЖЖ, там никто даже не заметил грубой ошибки в алгоритме (отсутствие откатов), которая была исправлена в 2.0.


Ну, так в ЖЖ (как и в форумах) это норма. Там вообще сообщения серьезно редко рассматриваются.

DM>Можно сделать версию 3.0, но что с ней потом делать?


Публиковать.

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

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

Но, естественно, это потребует от тебя некоторого времени и сил. Причем не только на написание текста, но и на доработку тестов и вообще кода. Скажем было бы здорово если бы ты попытался совместить все три метода (генерацию КА, мемоизацию и комбинаторы генерирующие фунции рекурсивного спуска с откатами) в одно единое решение. Это было бы отличным финалом для подобной статьи, и не пришлось бы людям объяснять, что в статье разбираются три разных темы.

VD>>1. Четко объяснить к чему там комбинаторы строящие ДКА.

VD>>2. Четко указать, что они сами по себе могут парсить только регулярные грамматик.

DM>Этот вопрос еще требует изучения.


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

DM> Совершенно не факт, что такими грамматиками их возможности ограничены.


Факт и научный. Я не силен в теории (ссылок не помню), но уверен, что mefrill легко подбросит нам ссылки на работы где это доказывается.

DM>Напомню, что там магазинный автомат (со стеком), а не простой ДКА.


Стоп. О чем мы говорим? В Яке действительно магазинный автомат. Если у тебя есть стек, то опять же я эту тему не просек. Можно об этом по подробнее?

Собственно очень простой вопрос. Можно ли с помощью КА сгенерированного твоими комбпнаторами распознать не под-строки (как в тесте), а полноценно распознать теги в ХМЛ (с вложенностями)? Если можно, то это уже конечно не просто конечные автоматы, но тогда опят же — это проблема статьи, так как уловить эту тонкость лично мне не удалось (и я не одинок в этом).

VD>>3. Обяснить (а лучше пказать) как комбинаторы коненых автоматов можно использовать для парсинга нерегулярных грамматик.

VD>>4. Расширить раздел про мемоизацию добавив в него код демонстриующий этот подход и тесты демонстрирующие выигрышь/проигрышь от полной и частичной мемоизации.

DM>Имеющий глаза да увидит. Код там есть.


Ну, вот ты вроде глаза имеешь? Так прочти еще раз пункты 3/4 и увидь, что речь идет не о коде примитивного примера реконструирующего принцип, а коде который может продемонстрировать характеристики предложенных решений. Скажем в тестах по парсингу ХМЛ-я конечно же нужно вместо поиска подстроки произвести полноценный парсинг ХМЛ-я. Если сделать грамматику с большим количеством откатов, то на базе этого примера можно еще проверить и мемоизирующий алгоритм.

VD>>Готов помочь в этом деле при условии, что статья в последсвии будет опубликована на РСДН.


DM>Спасибо, подумаю. Вообще, мне эта тема порядком поднадоела уже. Восьмой раз пережевывать одно и то же не слишком охота.


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

DM>Ошибаешься. По крайней мере второй и третий парсек, с которыми я имел дело. Примеры на окамле — да, возвращают функции.


А что же возвращает на сегодня Парске?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.07.10 23:02
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>К тому же четвертый раздел составляет половину статьи по объему. Вывод получается только один. Автор рассматривает генерацию КА как самый лучший способ оптимизации комбинаторных парсеров. При этом возникает масса вопросов:

VD>1. Почему вообще рассматривается более ограниченное решение (ведь КА не позволяют парсить не регулярные грамматики).

Да там магазинный автомат генерируется (МП-автомат), который как раз парсит почти все.
Re[29]: PEG vs RegExp
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.10 12:05
Оценка:
Здравствуйте, gandjustas, Вы писали:

L>>Интересно. Может дело в том, что у тех, кто не пользуется регэкспами просто нет нормальных инструментов? Скажем, если опросить работающих под никсами и под виндами — не окажется ли, что с регэкспами значительно меньше работают под виндами, а под никсами их используют более 50% (цифра от балды).

G>Возможно, в винде банально command line меньше юзают, а в IDE не сильно нужны regexp_ы.

Я и говорю, что сам пёрл тут вряд ли замешан.

L>>Тогда окажется, что дело не в том, перловый программист или нет. Я вот не перловый, но awk/sed и тем более grep пользую постоянно.

G>А что ты делаешь с их помощью?

Фильтр и изменение строк. Конкретных задач много. На что только не пойдёт человек, чтобы не пользоваться FAR и IDE

1. Работа с файлами — поиск, выделение, собственные скрипты для быстрой работы с ФС и специфичным для меня.
2. Переформатирование строк (cvs -> sql), частичное переформатирование (формат дат)
3. Инкрементальный поиск в vim-е, замена однотипных, но не одинаковых строк.
4. awk /pattern/ {action} или sed для обработки только нужного (выбор всех строк кроме таких-то).
5. grep для выделения нужного (цветом, фильтрацией).
...

В общем command line, да. Если рассматривать конкретные задачи, то в целом получается быстрее, чем в IDE, хотя есть задачи и отстающие — например, аналог поиска конкретного класса. В Eclipse есть Open Type, шелла же с инкрементальным поиском я пока не видел. В zsh используется несколько неудобный для данной задачи подход. Может быть можно сделать похоже, расширив zsh completion, но я не изучал его глубоко. Поэтому я использую другой подход, который проигрывает Open Type, но не сильного много.
Re[30]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.07.10 12:15
Оценка:
Здравствуйте, lomeo, Вы писали:


L>>>Тогда окажется, что дело не в том, перловый программист или нет. Я вот не перловый, но awk/sed и тем более grep пользую постоянно.

G>>А что ты делаешь с их помощью?

L>Фильтр и изменение строк. Конкретных задач много. На что только не пойдёт человек, чтобы не пользоваться FAR и IDE



L>1. Работа с файлами — поиск, выделение, собственные скрипты для быстрой работы с ФС и специфичным для меня.

L>2. Переформатирование строк (cvs -> sql), частичное переформатирование (формат дат)
L>3. Инкрементальный поиск в vim-е, замена однотипных, но не одинаковых строк.
L>4. awk /pattern/ {action} или sed для обработки только нужного (выбор всех строк кроме таких-то).
L>5. grep для выделения нужного (цветом, фильтрацией).
L>...

Меня больше интересуют не сами манипуляции, а их цели, касаемо конкретно разработки.
Re[31]: PEG vs RegExp
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 09.07.10 12:28
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>Меня больше интересуют не сами манипуляции, а их цели, касаемо конкретно разработки.


Навигация, генерация, иногда анализ.
Re[9]: PEG vs RegExp
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 09.07.10 16:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, то что опсано в статье это вообще еще то извращение. Преобразовывать перед парсингом исходную строку в список состоящий из символов и набора ленивых ссылок — это еще то извращение.

VD>Она конечно что-то ускоряет, но далеко не так как это требуется для реального применения.
VD>Плюс все зависит от грамматики. Те же выраженя можно парсить со скоростью звука без мемоизации. В тестах макроса Nemerle.Peg вот такая грамматика:
VD>...
VD>Парсится за вполне приемлемое время.

В твоей грамматике нет сильно ветвистых правил, она-то быстро разбирается. В таких простых случаях действительно мой подход с мемоизацией мало даст, т.к. подготовка данных съест кучу времени. Именно поэтому я не стал этот подход добавлять в сравнение с XML примером. А вот в языках программирования правила нередко сильно ветвистые, там без мемоизации разбор с откатами вообще неприменим на примерах длиннее нескольких строк.

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


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

DM>>Константного времени парсинга не бывает (линейное время это не константное).


VD>Ты опять невнимательно читаешь. Я не говорил о константном времени парсинга.


Твои слова: "Она обеспечивает теоретическое константное время парсинга, но при этом требует линейного увеличения объема памяти (количество правил * на количество сиволов во входной строке)". Вторая оценка касается всей строки, как мне понять, что первая оценка — для одного символа?

VD>Собственно тема эта мне самому очень интересно, так что любые качественные исследования будут кстати. Так что с удовольствием помогу сделать статью если не идеальной, то хотя бы такой чтобы до нее трудно было докапываться.


VD>Но, естественно, это потребует от тебя некоторого времени и сил. Причем не только на написание текста, но и на доработку тестов и вообще кода. Скажем было бы здорово если бы ты попытался совместить все три метода (генерацию КА, мемоизацию и комбинаторы генерирующие фунции рекурсивного спуска с откатами) в одно единое решение.


Хорошо, подумаю над этим.


VD>>>2. Четко указать, что они сами по себе могут парсить только регулярные грамматик.


DM>>Этот вопрос еще требует изучения.


VD>Да, ну? Примерно настолько насколько требует изучения вопрос действия земного притяжения. Есть туча работ доказывающих это.


DM>> Совершенно не факт, что такими грамматиками их возможности ограничены.


VD>Факт и научный. Я не силен в теории (ссылок не помню), но уверен, что mefrill легко подбросит нам ссылки на работы где это доказывается.


DM>>Напомню, что там магазинный автомат (со стеком), а не простой ДКА.


VD>Стоп. О чем мы говорим? В Яке действительно магазинный автомат. Если у тебя есть стек, то опять же я эту тему не просек. Можно об этом по подробнее?


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

VD>Собственно очень простой вопрос. Можно ли с помощью КА сгенерированного твоими комбпнаторами распознать не под-строки (как в тесте), а полноценно распознать теги в ХМЛ (с вложенностями)? Если можно, то это уже конечно не просто конечные автоматы, но тогда опят же — это проблема статьи, так как уловить эту тонкость лично мне не удалось (и я не одинок в этом).


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


DM>>Ошибаешься. По крайней мере второй и третий парсек, с которыми я имел дело. Примеры на окамле — да, возвращают функции.


VD>А что же возвращает на сегодня Парске?


data ParsecT s u m a
И потом отдельные функции вроде runParserT для применения собранной комбинаторами структуры ко входному потоку.
Re[10]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.10 17:59
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>В твоей грамматике нет сильно ветвистых правил, она-то быстро разбирается. В таких простых случаях действительно мой подход с мемоизацией мало даст, т.к. подготовка данных съест кучу времени. Именно поэтому я не стал этот подход добавлять в сравнение с XML примером. А вот в языках программирования правила нередко сильно ветвистые, там без мемоизации разбор с откатами вообще неприменим на примерах длиннее нескольких строк.


В таких языках ее правил много и (главное!) много файлов большого размера. И сдается мне, что описанный подход на практике окажется практически не применимым. Меж тем большинство современных языков имеет близкие к LL(1) грамматик которые можно подвергнуть правой факторизации и получить близкое к линейному время.

В конце-концов когда люди пишут парсеры вручную, то они именно так и делают.

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

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


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


К сожалению не все так просто. В немерловом макросе мы имеем АСТ грамматики, но вот так вот взять и понять что нужно мемоизировать, а что нет не так просто. Так что это открытый вопрос.

DM>Твои слова: "Она обеспечивает теоретическое константное время парсинга,


Сори, оговорился. Имелось в виду линейное конечно же.

VD>>Но, естественно, это потребует от тебя некоторого времени и сил. Причем не только на написание текста, но и на доработку тестов и вообще кода. Скажем было бы здорово если бы ты попытался совместить все три метода (генерацию КА, мемоизацию и комбинаторы генерирующие фунции рекурсивного спуска с откатами) в одно единое решение.


DM>Хорошо, подумаю над этим.


Давай! Надеюсь, что решение будет положительным.

DM>Влад, попробуй отвечать не по предложениям, а хотя бы по абзацам.


Это тяжело.

DM>Автоматы, описанные в статье, имеют стек, куда кладут позиции для откатов.


ОК. А зачем откаты если нет рекурсии? Или она все же есть?

DM>Описанные там комбинаторы не дают нормального способа определять рекурсивные правила, однако это больше ограничение интерфейса, чем "движка", ибо в тестовом примере как минимум одно рекурсивное правило вводится и успешно используется ("все до заданной строки"), просто вводится оно манипуляциями над графом, а не комбинаторами верхнего уровня.


"Все до заданной строки" аналогично регексу ".*строка" где строка и есть та самая строка.
К тому же если это делается не с помощью комбинаторов, то на построитель прасеров это не тянет.
Может имеет смыл доработать автоматный вариант так чтобы он позволял создавать полноценные парсеры. Пусть даже это будет комбинация из разных парсеров. Это все равно должно быть весьма эффективно.

VD>>А что же возвращает на сегодня Парске?


DM>data ParsecT s u m a

DM>И потом отдельные функции вроде runParserT для применения собранной комбинаторами структуры ко входному потоку.

"ParsecT s u m a" — это все равно что ничего не сказать. Особенно с дебильным подходом хаскелистов назвать все однобуквенными идентификаторами. Так что вопрос остается. Что за данные они формируют?
И почему это не помогает парсеку быть бысьрым (гы-гы)?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: PEG vs RegExp
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 11.07.10 11:07
Оценка:
Здравствуйте, VladD2, Вы писали:

DM>> А вот в языках программирования правила нередко сильно ветвистые, там без мемоизации разбор с откатами вообще неприменим на примерах длиннее нескольких строк.


VD>В таких языках ее правил много и (главное!) много файлов большого размера. И сдается мне, что описанный подход на практике окажется практически не применимым. Меж тем большинство современных языков имеет близкие к LL(1) грамматик которые можно подвергнуть правой факторизации и получить близкое к линейному время.


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

DM>>Автоматы, описанные в статье, имеют стек, куда кладут позиции для откатов.


VD>ОК. А зачем откаты если нет рекурсии? Или она все же есть?


Чтобы отличать "this is a long statement" от "this is a long expression". Ocamlyacc, будучи LR(1) парсером, с таким не справляется, например.

DM>>Описанные там комбинаторы не дают нормального способа определять рекурсивные правила, однако это больше ограничение интерфейса, чем "движка", ибо в тестовом примере как минимум одно рекурсивное правило вводится и успешно используется ("все до заданной строки"), просто вводится оно манипуляциями над графом, а не комбинаторами верхнего уровня.


VD>"Все до заданной строки" аналогично регексу ".*строка" где строка и есть та самая строка.


Верно, и как это реализуется обычно?

VD> Может имеет смыл доработать автоматный вариант так чтобы он позволял создавать полноценные парсеры. Пусть даже это будет комбинация из разных парсеров. Это все равно должно быть весьма эффективно.


Согласен.

VD>>>А что же возвращает на сегодня Парске?


DM>>data ParsecT s u m a

DM>>И потом отдельные функции вроде runParserT для применения собранной комбинаторами структуры ко входному потоку.

VD>"ParsecT s u m a" — это все равно что ничего не сказать. Особенно с дебильным подходом хаскелистов назвать все однобуквенными идентификаторами. Так что вопрос остается. Что за данные они формируют?


Сейчас посмотрел исходники, там структура, внутри которой таки функция.

VD>И почему это не помогает парсеку быть бысьрым (гы-гы)?


Напереобобщали.
Re: PEG vs RegExp
От: anonymous Россия http://denis.ibaev.name/
Дата: 15.07.10 14:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В частности, они как были, так и остались "write only" – будучи единожды написанными, они практически не поддаются прочтению. Оно и понятно, не так ведь просто догадаться, что делает набор из палочек и скобочек типа ("(\\"|\\\\|[^"])*"|/\*.*\*/|//[^\r]*) (если вы не смогли догадаться, то это выделение комментариев в С-подобном языке).


Убрал первую часть выражения, потому что это про строки, а не комментарии. А комментарии так.
qr/
    # coments are:
    # 1. /* ... */
    /\*.*\*/
        | # or
    # 2. // ...
    //[^\r]*
/x;

Только для чтения теперь? Плюс к этому другие способы повышения читаемости, уже предложенные здесь.
Re: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 15.07.10 15:33
Оценка:
Здравствуйте, VladD2, Вы писали:

Насколько я понял из этой темы, простые задачи поиска/замены лучше все же решать RegExp-ом.
Более сложные задачи уже проще решать с помощью PEG.

Теперь давайте представим, что во всех языках присутствует поддержка PEG наравне с RegExp и каждый программист в мире знает PEG наравне с RegExp.
Так вот, не мог бы кто-нибудь привести пример задач для которых PEG подходит больше RegExp-ов?

Было бы очень интересно отложить теорию и "пощупать" на практике.

СУВ, Aikin

P.S. Задача должна быть такой, которую сейчас решают с помощью RegExp. Например валидация или поиск всех вхождений чего-либо в тексте. Т.е. XML прасеры и парсеры граматик не подходят.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[2]: PEG vs RegExp
От: z00n  
Дата: 15.07.10 22:27
Оценка:
Здравствуйте, Aikin, Вы писали:

A>Так вот, не мог бы кто-нибудь привести пример задач для которых PEG подходит больше RegExp-ов?


A>Было бы очень интересно отложить теорию и "пощупать" на практике.


A>СУВ, Aikin


A>P.S. Задача должна быть такой, которую сейчас решают с помощью RegExp. Например валидация или поиск всех вхождений чего-либо в тексте. Т.е. XML прасеры и парсеры граматик не подходят.


Приводили же: http://www.rsdn.ru/forum/philosophy/3863059.1.aspx
Автор: z00n
Дата: 01.07.10

Для задач, которые неплохо решаются регекспами, LPEG re выглядит, по крайней мере, не хуже.
Re[3]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 16.07.10 06:35
Оценка:
Здравствуйте, z00n, Вы писали:

Z>Приводили же: http://www.rsdn.ru/forum/philosophy/3863059.1.aspx
Автор: z00n
Дата: 01.07.10

Z>Для задач, которые неплохо решаются регекспами, LPEG re выглядит, по крайней мере, не хуже.
Угу, только, ИМО, единственный плюс LPEG в данном случае это средства композиции.

Но кто сказал, что для RegExp-а такое невозможно?
Используя средства языка:
В том же Ruby, Perl, Немерле можно использовать переменные в строковых литералах:
$local_name = "№;%*?*(;?*(;?"
$domain    = "%&%*#(#)(#)"

$regexp    = "$local_name@$domain"

По моему отлично.

Даже в C# не так уж и плохо получается:
var localName = "№;%*?*(;?*(;?";
var domain    = "%&%*#(#)(#)";

var regexp    = string.Format("{0}@{1}", localName, domain);


Можно расширить синтаксис регулярок с целью добавить встроенные возможности композиции. Как поступил Perl.
Ситнаксис может быть любым. Например так (я показываю идею):
var regexp = 
                @"{localName}@{domain}
                    localName = №;%*?*(;?*(;?
                    domain    = %&%*#(#)(#)"



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




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

СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[4]: PEG vs RegExp
От: z00n  
Дата: 17.07.10 00:03
Оценка:
Здравствуйте, Aikin, Вы писали:


A>Мой вопрос остается в силе. Но уже учитываем, что синтаксис регулярок можно расширять (в разумных пределах).


Проблема регулярок не в синтаксисе (это Влад так считает), а в том, что они, сами по себе, недостаточно выразительны для практических целей (если кто забыл, регекспы это пустая строка, литерал, конкатенация, альтерация, Kleene star — и все). Чтобы скомпенсировать недостаточную выразительность они обросли многочисленными ad-hoc расширениями (backreferences, greedy-nongreedy), попутно потеряв теоретическую чистоту и простоту реализации .

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

Что не так с регэкспами можно прочитать тут:
http://swtch.com/~rsc/regexp/regexp1.html (Cox в результате написал самую быструю на свете библиотеку регэкспов RE2)
... или тут:
http://www.inf.puc-rio.br/~roberto/docs/peg.pdf (в результате появился LPEG)
Re[19]: PEG vs RegExp
От: fddima  
Дата: 18.07.10 12:07
Оценка: 6 (1) -1
Здравствуйте, VladD2, Вы писали:

Извиняюсь, не успел ответить: свадьба и отпуск.

F>>При чём тут потоковый режим? Лексер не может раскрывать энтити — XmlTextReader это делает.

VD>Я не знаю что ты понимаешь под энтитями, но лексер может разпознать все кроме рекурсивных правил.
Под энтитями я понимаю entity (predefined (&lt;), character ({, internal и external — определяются DTD).

VD>Лексер я тут говорю весьма условно. Главное, что это не парсер. Он не позволяет распознать форат. Он только позволяет прочитать отдельные его элементы.

Именно формат с различными его расширениями (XML NS) и его ограничения (well-formed) XmlTextReader распознает.

F>>Я и говорю — что кардинально быстрее — нет, не напишешь. Все оптимизации которые используются XmlTextReader-ом, для меня лично — очевидны.

VD>Это все равно что ничего не сказать. Лично для меня очевидны все оптимизации которые я могу понять.
Логично. Я хотел сказать что, оптимизации которые там присутствуют актуальны для любого кода обрабатывающего текст в подобной манере.

F>> В основном это: не делать лишних проверок при обработке следующего символа, и уменьшение бранчинга проца.

VD>Это какой-то сумбур. Фактически там рукопашный парсер с морей мелких оптимизаций которые вытекают из знания формата и возможности спрямлять углы вручную.
Естественно.

VD>Учитывая что грамматика регулярная, фактически там имеет место ДКА на switch-ах (т.е. реализованный в виде кода, а не на базе таблицы переходов) с ручными оптимизациями. При просто грамотной реализации (а она там грамотная) скорость будет практически оптимальной.

Именно switch-и там используются в некритичных участках — во всех остальных выгоднее делать рукопашный while/if/else.

VD>При этом, конечно же такой распознаватель не может проверить правильность структуры документа и вообще оперировать структурой.

VD>Для этого требуется более высокого порядка — парсер.
Проверка документа на WF — делается сразу же по ходу дела. Если же структура документа задается через DTD/XML Schema — то, да, проверка на соотвествие схеме обычно реализуются уровнем выше, параллельно предоставляя приложению дополнительную информацию (так возникают аттрибуты заданные по умолчанию). С другой стороны для некоторых схем XML Schema 2.0 невозможно проверить правильность документа в потоковом режиме.

F>> Всего остального малой кровью не избежать. Плюс ко всему: поведение сильно зависит от настроек и некоторые из оптмизаций доступны только для определенных конфигураций.

VD>Тут я вообще не понимаю о чем идет речь.
Сам уже точно не помню, скорее всего подразумевалось, что поведение парсера в значительной мере зависит от его настроек -> поддержка NS, раскрывать/не раскрывать entity, обрабатывать/не обрабатывать DTD, как обрабатывать пробелы, — ещё какие-то были, и в зависимости от этих настроек становятся доступны некоторые оптимизации. При этом, по мелочам — в сумме могут давать достаточно существенный прирост в скорости обработки.

Я вообще всё к чему: XML и XmlTextReader сложнее, чем может показаться, а касательно к статье — сравнения/результаты не очень корректные.

ЗЫ: Большую часть мыслей, увы, после отпуска я уже забыл.
Re[5]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 19.07.10 06:34
Оценка:
Здравствуйте, z00n, Вы писали:

A>>Мой вопрос остается в силе. Но уже учитываем, что синтаксис регулярок можно расширять (в разумных пределах).


Z>Проблема регулярок не в синтаксисе (это Влад так считает), а в том, что они, сами по себе, недостаточно выразительны для практических целей (если кто забыл, регекспы это пустая строка, литерал, конкатенация, альтерация, Kleene star — и все). Чтобы скомпенсировать недостаточную выразительность они обросли многочисленными ad-hoc расширениями (backreferences, greedy-nongreedy), попутно потеряв теоретическую чистоту и простоту реализации.

Хотелось бы пример. Я понимаю, что форум Философия, но слов и болтологии в этой теме уже было достаточно.

Я хочу увидеть задачу на которой регэкспы "недостаточно выразительны для практических целей". Теоретическая чистота и простота реализации волнуют меня в последнюю очередь.


СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[6]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.10 06:39
Оценка:
Здравствуйте, Aikin, Вы писали:

A>Я хочу увидеть задачу на которой регэкспы "недостаточно выразительны для практических целей". Теоретическая чистота и простота реализации волнуют меня в последнюю очередь.

Email, уже десять раз приводили.

Кроме того постоянно кто-либо пытается парсить html или арифметические выражения с помощью regex.
Re[7]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 19.07.10 06:49
Оценка:
Здравствуйте, gandjustas, Вы писали:

A>>Я хочу увидеть задачу на которой регэкспы "недостаточно выразительны для практических целей". Теоретическая чистота и простота реализации волнуют меня в последнюю очередь.

G>Email, уже десять раз приводили.
Видел я его. И что? Разбей этот регэксп на составные части и будет не так страшно. Возможно не так хорошо как в том же PEG, но у регэкспа есть несомненный плюс -- он является стандартом и его знают все.

G>Кроме того постоянно кто-либо пытается парсить html или арифметические выражения с помощью regex.

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

СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[8]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.10 07:55
Оценка:
Здравствуйте, Aikin, Вы писали:

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


A>>>Я хочу увидеть задачу на которой регэкспы "недостаточно выразительны для практических целей". Теоретическая чистота и простота реализации волнуют меня в последнюю очередь.

G>>Email, уже десять раз приводили.
A>Видел я его. И что? Разбей этот регэксп на составные части и будет не так страшно.
Ну а дебажить это как?

A>Возможно не так хорошо как в том же PEG, но у регэкспа есть несомненный плюс -- он является стандартом и его знают все.

Это далеко не самое главное


G>>Кроме того постоянно кто-либо пытается парсить html или арифметические выражения с помощью regex.

A>Достать адреса всех картинок из html это парсить? ИМО, вполне себе задача для регэкспа.
Я говорю про парсинг html, ане про доставание урлов.

A>Делать что-то сложнее, а тем более парсить арифметические выражения (я как-то даже не представляю как это сделать)... сами себе злобные буратины.

Дык почитай форум, каждый месяц такие буратины появляются.
Re[9]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 19.07.10 08:13
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Email, уже десять раз приводили.

A>>Видел я его. И что? Разбей этот регэксп на составные части и будет не так страшно.
G>Ну а дебажить это как?
О, это уже интересно! А как с этим дела у всяких PEG-ов?
Для регекспов есть масса "дебагеров", которые подсвечивают разными цветами группы. Я так понимаю этого мало, так?

A>>Возможно не так хорошо как в том же PEG, но у регэкспа есть несомненный плюс -- он является стандартом и его знают все.

G>Это далеко не самое главное
Главное для чего?

A>>Делать что-то сложнее, а тем более парсить арифметические выражения (я как-то даже не представляю как это сделать)... сами себе злобные буратины.

G>Дык почитай форум, каждый месяц такие буратины появляются.
Но ведь это не проблема регулярок. Уверен, что был бы тот же ANTLR стандартом, то нашлись бы уникумы, которые картинки доставали бы им и вопили, что у низ ничего не поучается.

СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[10]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.10 08:43
Оценка:
Здравствуйте, Aikin, Вы писали:

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


G>>>>Email, уже десять раз приводили.

A>>>Видел я его. И что? Разбей этот регэксп на составные части и будет не так страшно.
G>>Ну а дебажить это как?
A>О, это уже интересно! А как с этим дела у всяких PEG-ов?
Это к Vlad2.

A>Для регекспов есть масса "дебагеров", которые подсвечивают разными цветами группы. Я так понимаю этого мало, так?

Когда regexp клеится из кусочков — конечно мало. Примерно как с SQL проблема.

A>>>Возможно не так хорошо как в том же PEG, но у регэкспа есть несомненный плюс -- он является стандартом и его знают все.

G>>Это далеко не самое главное
A>Главное для чего?
Я уже писал в теме выше.

A>>>Делать что-то сложнее, а тем более парсить арифметические выражения (я как-то даже не представляю как это сделать)... сами себе злобные буратины.

G>>Дык почитай форум, каждый месяц такие буратины появляются.
A>Но ведь это не проблема регулярок. Уверен, что был бы тот же ANTLR стандартом, то нашлись бы уникумы, которые картинки доставали бы им и вопили, что у низ ничего не поучается.
Регулярные выражения в принципе неспособны парсить нерешгулярные языки, а ANTLR — вполне. Если у кого-то не получится получить url из текста с его помощью, то проблема только в том кто писал грамматику.
Re[11]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 19.07.10 08:58
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Ну а дебажить это как?

A>>О, это уже интересно! А как с этим дела у всяких PEG-ов?
G>Это к Vlad2.
Хм, сказал что ПЕГ можно дебажить в отличии от регулярок ты, но отвечать должен Влад. С чего бы?

A>>Для регекспов есть масса "дебагеров", которые подсвечивают разными цветами группы. Я так понимаю этого мало, так?

G>Когда regexp клеится из кусочков — конечно мало. Примерно как с SQL проблема.
Ну а раскрыть тему?

A>>>>Возможно не так хорошо как в том же PEG, но у регэкспа есть несомненный плюс -- он является стандартом и его знают все.

G>>>Это далеко не самое главное
A>>Главное для чего?
G>Я уже писал в теме выше.
И ссылку ты дать не можешь?


В неконструктивное русло входит наш разговор.

G>Регулярные выражения в принципе неспособны парсить нерешгулярные языки, а ANTLR — вполне. Если у кого-то не получится получить url из текста с его помощью, то проблема только в том кто писал грамматику.

Так он грамматику написать не может. Она ведь будет сложнее чем тот же регексп. Но давай оставим это я в парсерах ни-бум-бум.

СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[12]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.10 09:18
Оценка:
Здравствуйте, Aikin, Вы писали:

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


G>>>>Ну а дебажить это как?

A>>>О, это уже интересно! А как с этим дела у всяких PEG-ов?
G>>Это к Vlad2.
A>Хм, сказал что ПЕГ можно дебажить в отличии от регулярок ты, но отвечать должен Влад. С чего бы?
ПЕГ дебажить нельзя, ПЕГ это нотация. Адекватная реализация PEG парсера есть только в nemerle.

A>>>Для регекспов есть масса "дебагеров", которые подсвечивают разными цветами группы. Я так понимаю этого мало, так?

G>>Когда regexp клеится из кусочков — конечно мало. Примерно как с SQL проблема.
A>Ну а раскрыть тему?
Тут уже много раз все это написали, лень повторятьсяю

A>>>>>Возможно не так хорошо как в том же PEG, но у регэкспа есть несомненный плюс -- он является стандартом и его знают все.

G>>>>Это далеко не самое главное
A>>>Главное для чего?
G>>Я уже писал в теме выше.
A>И ссылку ты дать не можешь?
Некайф искать, просто прочитай тему сначала перед тем как постить, возможно уже есть ответы на все твои вопросы.

G>>Регулярные выражения в принципе неспособны парсить нерешгулярные языки, а ANTLR — вполне. Если у кого-то не получится получить url из текста с его помощью, то проблема только в том кто писал грамматику.

A>Так он грамматику написать не может. Она ведь будет сложнее чем тот же регексп. Но давай оставим это я в парсерах ни-бум-бум.
А с чего ты взял что грамматика для поиска урлов в тексте будет сложнее чем regexp? Вообще регуляные части языков почти во всех парсерах именно регулярными выражениями и записываются за неименеем.
Re[13]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 19.07.10 09:41
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А с чего ты взял что грамматика для поиска урлов в тексте будет сложнее чем regexp? Вообще регуляные части языков почти во всех парсерах именно регулярными выражениями и записываются за неименеем.

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

СУВ, Aikin
ЗЫ
G>Некайф искать, просто прочитай тему сначала перед тем как постить, возможно уже есть ответы на все твои вопросы.
а с чего ты взял, что я не прочитал? Прочитал. Только вот не зацепилось ничего.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re: PEG vs RegExp
От: adontz Грузия http://adontz.wordpress.com/
Дата: 19.07.10 09:43
Оценка:
Здравствуйте, VladD2, Вы писали:

Влад, ты прав в целом, но есть один неучтённый тобою момент. Для 99% практических случаев регулярное выражение находится в гугле.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[13]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 19.07.10 10:00
Оценка:
Здравствуйте, gandjustas, Вы писали:


G>Тут уже много раз все это написали, лень повторятьсяю

G>Некайф искать, просто прочитай тему сначала перед тем как постить, возможно уже есть ответы на все твои вопросы.
Да, точно. В этой всей вышележащей болтологии пропустил интересную ветку: Re: PEG vs RegExp
Автор: jazzer
Дата: 01.07.10

Сейчас читаю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[14]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.07.10 11:07
Оценка:
Здравствуйте, Aikin, Вы писали:

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


G>>А с чего ты взял что грамматика для поиска урлов в тексте будет сложнее чем regexp? Вообще регуляные части языков почти во всех парсерах именно регулярными выражениями и записываются за неименеем.

A>О, насколько я понял, это и будет ответ на мой изначальный вопрос. Т.о. PEG и др. лучше регулярок только на задачах для которых регулярки совсем не предназначены. Меня этот ответ устраивает.
Главный прикол в том что регулярки предназначены для очень узкого круга задач. Современные расширения РВ, которые их делают не совсем регулярными, призваны решить часть проблем. Но я например не вижу смысла использовать расширенные РВ вместо удобного парсера.

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

A>СУВ, Aikin

A>ЗЫ
G>>Некайф искать, просто прочитай тему сначала перед тем как постить, возможно уже есть ответы на все твои вопросы.
A>а с чего ты взял, что я не прочитал? Прочитал. Только вот не зацепилось ничего.
Ты задаешь теже вопросы, которые уже задавали другие.
Re[14]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 19.07.10 11:08
Оценка:
Здравствуйте, Aikin, Вы писали:

A>Сейчас читаю.

Прочитал. Согласен с jazzer.

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

СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[2]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.07.10 14:48
Оценка:
Здравствуйте, adontz, Вы писали:

A>Влад, ты прав в целом, но есть один неучтённый тобою момент. Для 99% практических случаев регулярное выражение находится в гугле.


Понятно, что если она технология существует 40 лет, а вторая только внедряется, то какое-то время с готовыми грамматиками буте сложнее. Но со временем все выравнеется. LPEG уже победно шествует по планете. Думаю для него грамматики уже есть.

Плюс не сложно сделать фронтенд для спнтаксиса регулярных выражений, чтобы можно было применять и его.
Ну, и уж точно можно использовать имеющиеся реализации регексов, если используешь чужые грамматки в виде "черного ящика".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: PEG vs RegExp
От: Eugeny__ Украина  
Дата: 19.07.10 15:20
Оценка:
Здравствуйте, Jack128, Вы писали:

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


J>Ненавижу регулярки. 100 раз себя пытался заставить изучать на более менее прилично уровне — все без толку,этот синтаксис мя просто убивает.


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

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

Замкнутый круг выходит: я не использую PEG потому, что его нет в стандартной поставке, а его там не будет, пока не наберет популярность. Но беда в том, что большинство вполне устраивают регекспы, нет той killer feature у PEG, которую признали бы все.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[15]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 20.07.10 06:11
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Главный прикол в том что регулярки предназначены для очень узкого круга задач.

Кто-нибудь очертит этот круг задач? У парсеров круг задач еще меньше. В разы меньше.


Для меня это задачи валидации, поиска и замены. Да, таких задач не много, но задач для которых нужен полноценный парсер у меня вообще не было. ВООБЩЕ!
В чем приемущество парсеров для меня?

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

Ну и хорошо. Чем это плохо?

G>Но я например не вижу смысла использовать расширенные РВ вместо удобного парсера.

В чем его удобство?

G>Кроме того отсутствие штатных средств декомпозиции РВ еще сильнее сужает их область действия.

Как любят говорит популяризаторы PEG-ов: это вопрос реализации.

СУВ, Aikin

ЗЫ Получается как в анекдоте:

PEG лучше чем RegExp
Чем, чем лучше?
Чем RegExp, конечно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[16]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.07.10 06:43
Оценка:
Здравствуйте, Aikin, Вы писали:

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


G>>Главный прикол в том что регулярки предназначены для очень узкого круга задач.

A>Кто-нибудь очертит этот круг задач? У парсеров круг задач еще меньше. В разы меньше.
Это заблуждение. Регулярные выражения — тоже парсеры.
Вообще у парсеров (в том числе и РВ) две задачи:
1)Проверка соответствия строки некоторому языку
2)Получения некоторой структуры из строки (последовательности символов)

РВ довольно хорошо решают первую задачу и почти никак вторую.

A>Для меня это задачи валидации, поиска и замены. Да, таких задач не много, но задач для которых нужен полноценный парсер у меня вообще не было. ВООБЩЕ!

A>В чем приемущество парсеров для меня?
А может и ни в чем. Почему должно быть преимущество для тебя?


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

A>Ну и хорошо. Чем это плохо?
Тем что они лишают РВ основных преимуществ. Я это уже писал в посте.


G>>Но я например не вижу смысла использовать расширенные РВ вместо удобного парсера.

A>В чем его удобство?
В декомпозиции и описании вывода.
Re[17]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 20.07.10 07:11
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Главный прикол в том что регулярки предназначены для очень узкого круга задач.

A>>Кто-нибудь очертит этот круг задач? У парсеров круг задач еще меньше. В разы меньше.
G>Это заблуждение.
Заблуждение считать это заблуждением.

G> Регулярные выражения — тоже парсеры.

Рад за них. Мне, как практику, от этого ни тепло ни холодно.

G>Вообще у парсеров (в том числе и РВ) две задачи:

G>1)Проверка соответствия строки некоторому языку
G>2)Получения некоторой структуры из строки (последовательности символов)

G>РВ довольно хорошо решают первую задачу и почти никак вторую.

А пацаны-то не знают... и успешно решают задачи поиска/замены регулярками

A>>Для меня это задачи валидации, поиска и замены. Да, таких задач не много, но задач для которых нужен полноценный парсер у меня вообще не было. ВООБЩЕ!

A>>В чем приемущество парсеров для меня?
G>А может и ни в чем. Почему должно быть преимущество для тебя?
Изначальный посыл был в том, что PEG намного лучше, чем RegExp. Меня можно рассматривать как среднестатистического программиста.
Ну раз нет приемущества для меня, то Ок. Заканчиваем. Ты остаешься при своем мнении, я продолжаю юзать регулярки.


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

A>>Ну и хорошо. Чем это плохо?
G>Тем что они лишают РВ основных преимуществ. Я это уже писал в посте.
Это только твое мнение.

СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[18]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.07.10 07:37
Оценка:
Здравствуйте, Aikin, Вы писали:

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


G>>Вообще у парсеров (в том числе и РВ) две задачи:

G>>1)Проверка соответствия строки некоторому языку
G>>2)Получения некоторой структуры из строки (последовательности символов)

G>>РВ довольно хорошо решают первую задачу и почти никак вторую.

A>А пацаны-то не знают... и успешно решают задачи поиска/замены регулярками

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

От того что ты не понимаешь парсинг он не становится менее полезным

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

A>>>Ну и хорошо. Чем это плохо?
G>>Тем что они лишают РВ основных преимуществ. Я это уже писал в посте.
A>Это только твое мнение.
Нет, это вообще-то научные факты. Вот что касается "удобства" и "подходящести" это как раз мнения.

Если ты не в курсе:
Регулярные выражения соответствуют недетерминированным конечным автоматам, которые почти всегда можно привести к детерминированным, которые в свою очередь парсят текст за линейное время (1) и никогда не зацикливаются (2), но парсят только регулярные языки.
Если расширить регулярные выражения, то приводить их к конечным автоматам становится сложнее и сложность парсинга возрастает до экспоненциальной в худшем случае, а также появляется зависимость от вида грамматики (рекурсивность), в таких случаях преимуществ перед обычным парсерами нету.
Re[19]: PEG vs RegExp
От: Aikin Беларусь kavaleu.ru
Дата: 20.07.10 09:30
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Если что любая задача может быть сведена к проверке соответствия строки некоторому языку

G>"Пацаны" видимо действительно не знают. Поиск (и как следствие замена) задача изначально являющаяся задачей парсинга, а именно проверки соответствия строки языку (поиск) и доставание данных из строки и последующей их заменой на другие значения (замена).

G>От того что ты не понимаешь парсинг он не становится менее полезным

Это уже интересней (тут
Автор: gandjustas
Дата: 19.07.10
):

G>>Кроме того постоянно кто-либо пытается парсить html или арифметические выражения с помощью regex.
A>Достать адреса всех картинок из html это парсить? ИМО, вполне себе задача для регэкспа.
Я говорю про парсинг html, ане про доставание урлов.

Что-то вы начинаете заговариваться.


G>Если ты не в курсе:

G>Регулярные выражения соответствуют недетерминированным конечным автоматам, которые почти всегда можно привести к детерминированным, которые в свою очередь парсят текст за линейное время (1) и никогда не зацикливаются (2), но парсят только регулярные языки.
В этом топике это утверждение проскакивало 100 раз. Как не быть в курсе-то?

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

Сколько можно повторять мою позицию (у Вас амнезия?): каждому инструменту свой круг задач.
Парсить html (дабы получить структуру) я регулярками не буду, доставать же из того же html урлы или заменять их я буду именно регекспами. Как только регулярки упрутся в производительность (экспоненциальное время и проч бла-бла-бла) я уже буду рассматривать альтернативы.
Что непонятного?


В общем заканчиваем. Конструктивного обсуждения с Вами, видимо, не получится.

СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[20]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.07.10 09:41
Оценка:
Здравствуйте, Aikin, Вы писали:

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


G>>Если что любая задача может быть сведена к проверке соответствия строки некоторому языку

G>>"Пацаны" видимо действительно не знают. Поиск (и как следствие замена) задача изначально являющаяся задачей парсинга, а именно проверки соответствия строки языку (поиск) и доставание данных из строки и последующей их заменой на другие значения (замена).

G>>От того что ты не понимаешь парсинг он не становится менее полезным

A>Это уже интересней (тут
Автор: gandjustas
Дата: 19.07.10
):

A>

G>>Кроме того постоянно кто-либо пытается парсить html или арифметические выражения с помощью regex.
A>>Достать адреса всех картинок из html это парсить? ИМО, вполне себе задача для регэкспа.
A>Я говорю про парсинг html, ане про доставание урлов.

A>Что-то вы начинаете заговариваться.
Что смутило? Доставание урлов из текста не является парсингом HTML, это может быть вообще любой текст.

G>>Если ты не в курсе:

G>>Регулярные выражения соответствуют недетерминированным конечным автоматам, которые почти всегда можно привести к детерминированным, которые в свою очередь парсят текст за линейное время (1) и никогда не зацикливаются (2), но парсят только регулярные языки.
A>В этом топике это утверждение проскакивало 100 раз. Как не быть в курсе-то?
Это единственные объективные качества регулярных выражений, а почему-то многие вместо объективных критерием используют сильно субъективные.

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

A>Сколько можно повторять мою позицию (у Вас амнезия?): каждому инструменту свой круг задач.
Нет, я не могу понять зачем придерживаться регэкспов с убогим синтаксисом для парсинга нерегулярных языков.

A>Парсить html (дабы получить структуру) я регулярками не буду, доставать же из того же html урлы или заменять их я буду именно регекспами. Как только регулярки упрутся в производительность (экспоненциальное время и проч бла-бла-бла) я уже буду рассматривать альтернативы.

Доставание урлов и текста, к счатью для тебя, это регулярная задача.

A>Что непонятного?

См выше.
Re[5]: PEG vs RegExp
От: mrTwister Россия  
Дата: 22.07.10 09:28
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Такое кажись только perl и поддерживает, но там regex по мощности сравнимы с PEG, но имеют гораздо более хреновый синтаксис.


http://msdn.microsoft.com/en-us/library/az24scfc.aspx#grouping_constructs
лэт ми спик фром май харт
Re[3]: PEG vs RegExp
От: Poudy Россия  
Дата: 22.07.10 18:11
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Почему? Вернитесь к началу сообщения.

O>>Все гораздо проще. Я, например, никогда не слышал про PEG. Думаю таких, как я, большинство. Благодаря форуму узнал и буду пробовать. И никакой интриги.

VD>Проблема в том что пробовать не чего (ну, если конечно ты не собираешся пересесть на Nemerle или Lua). И, что самое обидное, вряд ли появится в ближайшее время? Почему? Вернись к началу сообщения
Автор: VladD2
Дата: 30.06.10
.


А я вот давеча написал packrat под C#. Нужен был общий парсер для кучи языков в наш продукт. Собственно, штука-то простая — регулярные выражения со ссылками на другие регулярные выражения. Самое геморное было — написать разбор для языка описания этих выражений ... тут уж не деться никуда ... и потом правильное кеширование в pakrat. По сути просто, но получилось только раза с пятого не меньше (и каждый раз с чистого листа). Кстати, нормальную выдачу ошибок разбора до сих пор сделать так и не получилось.
Re[19]: PEG vs RegExp
От: Poudy Россия  
Дата: 22.07.10 18:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>... При этом, конечно же такой распознаватель не может проверить правильность структуры документа и вообще оперировать структурой. Для этого требуется более высокого порядка — парсер.


Влад, не рой себе яму — по факту fddima совершенно прав. Совершенно насрать, сколько процентов кода в XmlTextReader можно считать ДКА. Фактом является то, что XmlTextReader помнит вложенность узлов, ругается на неверную структуру (!!!) документа и даже может проверять соответствие схеме. И даже если это там просто стек вложенности узлов и в нем ссылочки на схему, формально это уже не ДКА. Признай ошибку и отстань от человека уже.
Re[3]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 23.07.10 06:13
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>LPEG уже победно шествует по планете.

Имхо, это излишне оптимистичное заявление для библиотеки, которая
1) появилась только в 2008 году
2) даже не дошла до первой стабильной версии (сейчас это версия 0.9)
3) написана для языка Lua, который сам по себе далеко не "победно шествует по планете", ибо используется в основном для скриптования программ, написанных на других языках, а не для написания самостоятельных программ. Т.е. чтобы заюзать его, к примеру, из С, мне надо сначала подключить Луа, что отдельный геморрой, потом дать ему все распарсить, а потом, дергая непосредственно Lua C API, разбираться с потрохами, которые он нагенерил в памяти в процессе парсинга, чтобы достать информацию, которая мне нужна.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: PEG vs RegExp
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 23.07.10 08:41
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Имхо, это излишне оптимистичное заявление для библиотеки, которая

J>1) появилась только в 2008 году
J>2) даже не дошла до первой стабильной версии (сейчас это версия 0.9)
J>3) написана для языка Lua, который сам по себе далеко не "победно шествует по планете", ибо используется в основном для скриптования программ, написанных на других языках, а не для написания самостоятельных программ. Т.е. чтобы заюзать его, к примеру, из С, мне надо сначала подключить Луа, что отдельный геморрой, потом дать ему все распарсить, а потом, дергая непосредственно Lua C API, разбираться с потрохами, которые он нагенерил в памяти в процессе парсинга, чтобы достать информацию, которая мне нужна.

Вообще говоря, утверждение об излишней оптимистичности верное, а вот третий пункт не соответствует действительности: из С/С++ подключить lua очень просто, получить результаты работы тоже.
Re[5]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 23.07.10 09:09
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Вообще говоря, утверждение об излишней оптимистичности верное, а вот третий пункт не соответствует действительности: из С/С++ подключить lua очень просто, получить результаты работы тоже.

Я имею в виду, LPEG создает многократно вложенную таблицу с результатами парсинга, мне надо по ней как-то ходить, чтобы понять, что и где у меня распарсилось.
Со Спиритом я прямо в семантических действиях рядом с конкретным правилом указываю, в какой мой С++-объект (или поле объекта) положить результат (типизированный!) или какую плюсовую функцию позвать (опять же типизированно!), и после того, как спирит отыграет, у меня будет все готово в моих объектах. А с Луа у меня будет таблица, внутри нее еще таблица и т.д, и нужно будет по ней гулять, дергая разнообраные АПИ. Либо загрузить всю таблицу нетипизированно в какой-то обобщенный строковый контейнер (для этого можно обобщенный хелпер написать) и потом гулять по нему, опять же руками анализируя типы и содержимое. Имхо, гемор.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: PEG vs RegExp
От: night beast СССР  
Дата: 23.07.10 09:14
Оценка:
Здравствуйте, jazzer, Вы писали:

N>>Вообще говоря, утверждение об излишней оптимистичности верное, а вот третий пункт не соответствует действительности: из С/С++ подключить lua очень просто, получить результаты работы тоже.

J>Я имею в виду, LPEG создает многократно вложенную таблицу с результатами парсинга, мне надо по ней как-то ходить, чтобы понять, что и где у меня распарсилось.
J>Со Спиритом я прямо в семантических действиях рядом с конкретным правилом указываю, в какой мой С++-объект (или поле объекта) положить результат (типизированный!) или какую плюсовую функцию позвать (опять же типизированно!), и после того, как спирит отыграет, у меня будет все готово в моих объектах. А с Луа у меня будет таблица, внутри нее еще таблица и т.д, и нужно будет по ней гулять, дергая разнообраные АПИ. Либо загрузить всю таблицу нетипизированно в какой-то обобщенный строковый контейнер (для этого можно обобщенный хелпер написать) и потом гулять по нему, опять же руками анализируя типы и содержимое. Имхо, гемор.

а спирит левую рекурсию могёт?
Re[6]: PEG vs RegExp
От: z00n  
Дата: 23.07.10 10:00
Оценка:
Здравствуйте, jazzer, Вы писали:

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


N>>Вообще говоря, утверждение об излишней оптимистичности верное, а вот третий пункт не соответствует действительности: из С/С++ подключить lua очень просто, получить результаты работы тоже.

J>Я имею в виду, LPEG создает многократно вложенную таблицу с результатами парсинга, мне надо по ней как-то ходить, чтобы понять, что и где у меня распарсилось.
J>Со Спиритом я прямо в семантических действиях рядом с конкретным правилом указываю, в какой мой С++-объект (или поле объекта) положить результат (типизированный!) или какую плюсовую функцию позвать (опять же типизированно!), и после того, как спирит отыграет, у меня будет все готово в моих объектах.

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

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


Как язык, луа куда больше, чем с++ подходит для написания компиляторов
В ней есть:
— GC
— TCO (tail call optimization)
— корутины
— все строки interned
— lua table кеится чем угодно, и быстрее, чем std:map
— есть по крайней мере 2 внешние приблуды для настоящего алгебраического pattern-matching
— LPEG немного быстрее Спирита, при нулевом времени компиляции.
Re[4]: PEG vs RegExp
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.07.10 11:38
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Имхо, это излишне оптимистичное заявление для библиотеки, которая

J>1) появилась только в 2008 году

Для библиотеки два года — это не так мало.

J>2) даже не дошла до первой стабильной версии (сейчас это версия 0.9)


В опен-сорсе версии не имеют такого большого значения. Есть масса продуктов которые используются десятки лет и при этом они так и не дошли до цифорки 1.

J>3) написана для языка Lua, который сам по себе далеко не "победно шествует по планете",


LPEG в основном написан на языке С. На Луа написан назначительный объем оберточного кода (чтобы эту библиотеку было удобно использовать из Луа). Так что ничто (ну, кроме, возможно, лицензии) не мешает 1 в 1 перенести ее куда угодно.

J>Т.е. чтобы заюзать его, к примеру, из С, мне надо сначала подключить Луа, что отдельный геморрой, потом дать ему все распарсить, а потом, дергая непосредственно Lua C API, разбираться с потрохами, которые он нагенерил в памяти в процессе парсинга, чтобы достать информацию, которая мне нужна.


Как я уже сказал выше — это не так.

ЗЫ

Я не утрвержадл, что регексы померли и теперь везде будет один ПЕГ. Я как раз сетовал на то, что косность мышления, лень, страх, незнание и другие пороки присущие программистам сдерживают прогресс. Так что, конечно же, ПЕГ пока не так распространен, но и говорить что его вообще нет тоже не неверно. Первые шаги сделаны. Дальше все будет зависить от того насколько гибким окажется программисткое сообщенство. Я свои пять копеек в процесс освоения ПЕГ-а уже внес.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 23.07.10 14:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я не утрвержадл, что регексы померли и теперь везде будет один ПЕГ. Я как раз сетовал на то, что косность мышления, лень, страх, незнание и другие пороки присущие программистам сдерживают прогресс. Так что, конечно же, ПЕГ пока не так распространен, но и говорить что его вообще нет тоже не неверно. Первые шаги сделаны. Дальше все будет зависить от того насколько гибким окажется программисткое сообщенство. Я свои пять копеек в процесс освоения ПЕГ-а уже внес.


Так а я в этой ветке вообще про регэкспы не говорил.
И то, что ты делаешь родной ПЕГ в Немерле, я только приветствую — у этого очень много плюсов.
Собственно, ровно по этим же причинам я на С++ предпочту Спирит.
Ну и потом, ПЕГ сам по себе не так уж важен по сравнению с рекурсивным спуском и EBNF, тем более что многие конструкции в том же Спирите — это не чистый EBNF, а с хорошей добавкой регэкс/ПЕГ-вкусностей. ПЕГ по сравнению с рекурсивным спуском хорош тем, что его можно заоптимизировать, но это (скорость парсинга, эффективность управления памятью) не всегда необходимо. Зачастую важнее просто удобный синтаксис, и языки с синтаксическими макросами, типа Немерле, очень способствуют созданию библиотек с удобным синтаксисом.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: PEG vs RegExp
От: Vain Россия google.ru
Дата: 18.01.11 08:00
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Z>>Это преувеличение:

Z>>- проект OMETA для C#, Javascript,Python, Ruby, Scheme, CL etc
Z>>- peg комбинаторный парсер входит в состав стандартной библиотеки Scala 2.8
Z>>- для Java их несколько штук (Rats, Mouse etc)
Z>>- для С, по крайней мере peg-leg: http://piumarta.com/software/peg/
Z>>- для C++ — PEG Template Library: http://code.google.com/p/pegtl7/

Z>>7Не всеми так же просто пользоваться, как LPEG или OMETA — но недостатка в парсерах определенно нет


VD>Конечно же хорошо, что что-то есть. Но все что ты перечислил не является альтернативой для регулярных выражений. Все это не находится "в шаговой доступности". Из перечисленного только С++-ное решение, и возможно Scala-ное, являются библиотеками которые можно легко вызвать из своего проекта. OMeta# же идет по старому доброму пути внешних утилит генераторов парсеров. Причем все с теми же ошибками.

Не легко, там C++0x используется:

Compiler

The PEGTL uses features from the C++0x standard, in particular variadic templates and r-value references. For development, GCC 4.5.1 is used, but any other compiler with sufficient C++0x support should work too.

А это значит никаких предыдущих компиляторов. Из-за этого никакой портируемости, по крайней мере пока что, т.е. в старые проекты это уж точно не добавишь.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[6]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 18.01.11 09:22
Оценка:
Здравствуйте, Vain, Вы писали:

Z>>>- для C++ — PEG Template Library: http://code.google.com/p/pegtl7/

V>Не легко, там C++0x используется:
V>

V>Compiler

V>The PEGTL uses features from the C++0x standard, in particular variadic templates and r-value references. For development, GCC 4.5.1 is used, but any other compiler with sufficient C++0x support should work too.

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

Boost.Spirit реализует PEG на С++ и работает со старыми компиляторами.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[7]: PEG vs RegExp
От: night beast СССР  
Дата: 18.01.11 09:25
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Boost.Spirit реализует PEG на С++ и работает со старыми компиляторами.


а не LL(oo) парсер?
Re[7]: PEG vs RegExp
От: Vain Россия google.ru
Дата: 18.01.11 09:27
Оценка:
Здравствуйте, jazzer, Вы писали:

Z>>>>- для C++ — PEG Template Library: http://code.google.com/p/pegtl7/

V>>Не легко, там C++0x используется:
V>>

V>>Compiler

V>>The PEGTL uses features from the C++0x standard, in particular variadic templates and r-value references. For development, GCC 4.5.1 is used, but any other compiler with sufficient C++0x support should work too.

V>>А это значит никаких предыдущих компиляторов. Из-за этого никакой портируемости, по крайней мере пока что, т.е. в старые проекты это уж точно не добавишь.
J>Boost.Spirit реализует PEG на С++ и работает со старыми компиляторами.
Непонятно тогда почему его не привели в качестве примера и по тестам оно уступает.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[8]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 18.01.11 09:51
Оценка: 3 (1)
Здравствуйте, night beast, Вы писали:

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


J>>Boost.Spirit реализует PEG на С++ и работает со старыми компиляторами.


NB>а не LL(oo) парсер?


http://www.boost.org/doc/libs/1_45_0/libs/spirit/doc/html/spirit/abstracts/parsing_expression_grammar.html

Или ты хотел сказать, что это не packrat?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: PEG vs RegExp
От: night beast СССР  
Дата: 18.01.11 09:55
Оценка:
Здравствуйте, jazzer, Вы писали:

J>>>Boost.Spirit реализует PEG на С++ и работает со старыми компиляторами.


NB>>а не LL(oo) парсер?


J>http://www.boost.org/doc/libs/1_45_0/libs/spirit/doc/html/spirit/abstracts/parsing_expression_grammar.html


гы. прикольно. не знал
Re[11]: PEG vs RegExp
От: vdimas Россия  
Дата: 20.01.11 17:49
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я не про объектник, а про сами сгенерированные файлы. Т.е. посмотреть, во что раскрываются шаблоны.

ВВ>Собственно, можно проще — как работает спирит? Он в компайл-тайме создает парсер или же выступает в роли этакого интерпретатора и работает исключительно в рантайме? Могу ли я в рантайме поменять грамматику?

Это не принципиально, т.к. используется примитивная технология построения комбинаторных парсеров. Т.е. никакой фазы преобразования, минимизации и ресолвинга конфликтов нет — тупо рекурсия с откатами. Соответственно, всерьез бустовские парсеры рассматривать не стоит, как и все остальные комбинаторные.

Как правильно сказали, всё отличие — это в степени "типизированности" вызовов. Если парсер построен целиком в compile-time — то многое инлайнится, или же имеем лишний уровень косвенности и вызов узлов через интерфейс, если парсер построен в рантайм.
Re[10]: PEG vs RegExp
От: vdimas Россия  
Дата: 20.01.11 17:55
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Ага. Вот опишешь 50 раз парсинг вещественного числа по IEEE — и задумаешься, что неплохо бы, наверное, для стандартных примитивов все же готовые парсеры иметь.


Вообще-то, там не нужен парсер. Эта грамматика из разряда регулярных, и boost::spirit только будет мешать тебе в этой задаче. Парсеры с откатами очень плохо ведут себя на автоматных грамматиках. Да еще чувствительны к порядку правил и к конкретным данным, в отличие от лексеров на ДКА с линейным разбором.
Re[11]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 21.01.11 00:21
Оценка: 5 (1)
Здравствуйте, vdimas, Вы писали:

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


J>>Ага. Вот опишешь 50 раз парсинг вещественного числа по IEEE — и задумаешься, что неплохо бы, наверное, для стандартных примитивов все же готовые парсеры иметь.


V>Вообще-то, там не нужен парсер. Эта грамматика из разряда регулярных, и boost::spirit только будет мешать тебе в этой задаче. Парсеры с откатами очень плохо ведут себя на автоматных грамматиках. Да еще чувствительны к порядку правил и к конкретным данным, в отличие от лексеров на ДКА с линейным разбором.

Ну так поэтому в Спирите и сделали очень быстрый парсер, специально заточенный под это дело, который рвет всякие scanf и atoi, бывшие до сих пор эталоном скорости парсинга чисел:
http://vi-k-d.blogspot.com/2010/04/boostspirit-vs-sscanf.html
http://alexott-ru.blogspot.com/2010/01/boostspirit2-vs-atoi.html
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[12]: PEG vs RegExp
От: SleepyDrago Украина  
Дата: 23.01.11 13:06
Оценка:
Здравствуйте, jazzer, Вы писали:

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


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


J>>>Ага. Вот опишешь 50 раз парсинг вещественного числа по IEEE — и задумаешься, что неплохо бы, наверное, для стандартных примитивов все же готовые парсеры иметь.


V>>Вообще-то, там не нужен парсер. Эта грамматика из разряда регулярных, и boost::spirit только будет мешать тебе в этой задаче. Парсеры с откатами очень плохо ведут себя на автоматных грамматиках. Да еще чувствительны к порядку правил и к конкретным данным, в отличие от лексеров на ДКА с линейным разбором.

J>Ну так поэтому в Спирите и сделали очень быстрый парсер, специально заточенный под это дело, который рвет всякие scanf и atoi, бывшие до сих пор эталоном скорости парсинга чисел:
J>http://vi-k-d.blogspot.com/2010/04/boostspirit-vs-sscanf.html
J>http://alexott-ru.blogspot.com/2010/01/boostspirit2-vs-atoi.html

strtod не особо "эталон". В хроме (v8) например переписали и получили существенный профит. Лично мне задачки с таким количеством парсинга чтобы увидеть разницу не попадались
Re[27]: PEG vs RegExp
От: Mamut Швеция http://dmitriid.com
Дата: 25.01.11 09:24
Оценка:
J>>Не только те основные преимущества, которые ты упомянул для "истинных регэкспов" (т.е. линейное время и т.д.), но и удобство перловых регэкспов, с их заглядываниями и обратными ссылками. Конкретно обратные ссылки Пег предоставить не может, и это, имхо, снижает ценность ПЕГа для использования в качестве поисковой строки от юзера.
G>Конкретно обратные ссылки — костыль, чтобы расширить класс языков, которые умеет парсить regex. Они сильно снижают читабельность.

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

J>>И вот тут регэкспы (вкупе с грепами, седами и перлами) рулят, по моему скромному опыту, причем рулят просто по критерию простоты и скорости достижения результата — написал за минуту, отладил за три, получил нужную информацию и все, твоя команда максимум в какой-нть bash_history останется.
G>Ну это только твой опыт, кроме перловых программистов наверное мало кто так массово пользуется рекэкспами.

Вообще-то, веб-программисты достаточно часто пользуются. Если от пользователя может прийти как «12,5» так и «12.5» в поле, то почти наверняка будет испольован коротенький регэксп типа /(\d+)(,|\.)*(\d+)*/. Который, при опыте, ничем не хуже, чем гипотетический [[Expr <- \d+ (,/.)* \d*]], который, кстати, нельзя применить прямо на месте и получить требуемые мне цифры/буквы.


dmitriid.comGitHubLinkedIn
Re[28]: Да, я некропостер :) (-)
От: Mamut Швеция http://dmitriid.com
Дата: 25.01.11 09:28
Оценка:


dmitriid.comGitHubLinkedIn
Re[28]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.01.11 09:36
Оценка: +1
Здравствуйте, Mamut, Вы писали:

J>>>Не только те основные преимущества, которые ты упомянул для "истинных регэкспов" (т.е. линейное время и т.д.), но и удобство перловых регэкспов, с их заглядываниями и обратными ссылками. Конкретно обратные ссылки Пег предоставить не может, и это, имхо, снижает ценность ПЕГа для использования в качестве поисковой строки от юзера.

G>>Конкретно обратные ссылки — костыль, чтобы расширить класс языков, которые умеет парсить regex. Они сильно снижают читабельность.

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

J>>>И вот тут регэкспы (вкупе с грепами, седами и перлами) рулят, по моему скромному опыту, причем рулят просто по критерию простоты и скорости достижения результата — написал за минуту, отладил за три, получил нужную информацию и все, твоя команда максимум в какой-нть bash_history останется.
G>>Ну это только твой опыт, кроме перловых программистов наверное мало кто так массово пользуется рекэкспами.

M>Вообще-то, веб-программисты достаточно часто пользуются. Если от пользователя может прийти как «12,5» так и «12.5» в поле, то почти наверняка будет испольован коротенький регэксп типа /(\d+)(,|\.)*(\d+)*/. Который, при опыте, ничем не хуже, чем гипотетический [[Expr <- \d+ (,/.)* \d*]], который, кстати, нельзя применить прямо на месте и получить требуемые мне цифры/буквы.


а replace(',','.'), который кстати гораздо очевиднее
Re[29]: PEG vs RegExp
От: Mamut Швеция http://dmitriid.com
Дата: 25.01.11 09:49
Оценка:
M>>Вообще-то, веб-программисты достаточно часто пользуются. Если от пользователя может прийти как «12,5» так и «12.5» в поле, то почти наверняка будет испольован коротенький регэксп типа /(\d+)(,|\.)*(\d+)*/. Который, при опыте, ничем не хуже, чем гипотетический [[Expr <- \d+ (,/.)* \d*]], который, кстати, нельзя применить прямо на месте и получить требуемые мне цифры/буквы.

G>а replace(',','.'), который кстати гораздо очевиднее


Ну, я как пример


dmitriid.comGitHubLinkedIn
Re[30]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.01.11 09:55
Оценка:
Здравствуйте, Mamut, Вы писали:


M>>>Вообще-то, веб-программисты достаточно часто пользуются. Если от пользователя может прийти как «12,5» так и «12.5» в поле, то почти наверняка будет испольован коротенький регэксп типа /(\d+)(,|\.)*(\d+)*/. Который, при опыте, ничем не хуже, чем гипотетический [[Expr <- \d+ (,/.)* \d*]], который, кстати, нельзя применить прямо на месте и получить требуемые мне цифры/буквы.


G>>а replace(',','.'), который кстати гораздо очевиднее


M>Ну, я как пример


Кстати касаемо PEG. С Peg можно без усилий написать парсер, который схавает множество форматов входной строки и выдаст число.
Re[31]: PEG vs RegExp
От: Mamut Швеция http://dmitriid.com
Дата: 25.01.11 12:21
Оценка: 1 (1)
M>>>>Вообще-то, веб-программисты достаточно часто пользуются. Если от пользователя может прийти как «12,5» так и «12.5» в поле, то почти наверняка будет испольован коротенький регэксп типа /(\d+)(,|\.)*(\d+)*/. Который, при опыте, ничем не хуже, чем гипотетический [[Expr <- \d+ (,/.)* \d*]], который, кстати, нельзя применить прямо на месте и получить требуемые мне цифры/буквы.

G>>>а replace(',','.'), который кстати гораздо очевиднее


M>>Ну, я как пример


G>Кстати касаемо PEG. С Peg можно без усилий написать парсер, который схавает множество форматов входной строки и выдаст число.


Зачем? То есть есть много задач, когда надо решить что-то среднее между банальным .replace'ом и полноценным парсером. PEG туда пока-то не помещается никак.


dmitriid.comGitHubLinkedIn
Re[32]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.01.11 12:30
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>>>Вообще-то, веб-программисты достаточно часто пользуются. Если от пользователя может прийти как «12,5» так и «12.5» в поле, то почти наверняка будет испольован коротенький регэксп типа /(\d+)(,|\.)*(\d+)*/. Который, при опыте, ничем не хуже, чем гипотетический [[Expr <- \d+ (,/.)* \d*]], который, кстати, нельзя применить прямо на месте и получить требуемые мне цифры/буквы.


G>>>>а replace(',','.'), который кстати гораздо очевиднее


M>>>Ну, я как пример


G>>Кстати касаемо PEG. С Peg можно без усилий написать парсер, который схавает множество форматов входной строки и выдаст число.


M>Зачем? То есть есть много задач, когда надо решить что-то среднее между банальным .replace'ом и полноценным парсером. PEG туда пока-то не помещается никак.


А конкретнее про эти "много задач". Обычно задачи, которые решаются regexp, являются частями более общих задач.

Если несложно приведи примеры обратного.
Re[33]: PEG vs RegExp
От: Mamut Швеция http://dmitriid.com
Дата: 25.01.11 14:19
Оценка:
M>>>>>>Вообще-то, веб-программисты достаточно часто пользуются. Если от пользователя может прийти как «12,5» так и «12.5» в поле, то почти наверняка будет испольован коротенький регэксп типа /(\d+)(,|\.)*(\d+)*/. Который, при опыте, ничем не хуже, чем гипотетический [[Expr <- \d+ (,/.)* \d*]], который, кстати, нельзя применить прямо на месте и получить требуемые мне цифры/буквы.

G>>>>>а replace(',','.'), который кстати гораздо очевиднее


M>>>>Ну, я как пример


G>>>Кстати касаемо PEG. С Peg можно без усилий написать парсер, который схавает множество форматов входной строки и выдаст число.


M>>Зачем? То есть есть много задач, когда надо решить что-то среднее между банальным .replace'ом и полноценным парсером. PEG туда пока-то не помещается никак.


G>А конкретнее про эти "много задач". Обычно задачи, которые решаются regexp, являются частями более общих задач.


Обычно «общие» задачи на практике даром не нужны Как в примере выше, ну не нужен мне парсер, который из каких-то там форматов перегоняет в цифры. У меня есть какие-то конкретных один-два формата, с которыми я работаю Обычно они спокойно ложатся в два-три регэкспа

G>Если несложно приведи примеры обратного.


есть у меня парсер мат. выражений на яваскрипте. уже готовый. переменные понимает и т.п. но не понимает проценты Имхо, было бы проще написать два выражения и снабдить их комментариями:
/(.+)(\d)\s+(\d+)\%/           /* 10 + 20  50% */
/(.+)\s*(\+|-)\s*(\d+)\%/      /* 10 + 20 + 50% */


чем вклиниваться в парсер и вообще

Да, я знаю, тут можно привести контрпример Но на данный момент это так и есть. Это кратко и емко уже описал Sinclair тут: http://rsdn.ru/forum/philosophy/4120092.1.aspx
Автор: Sinclair
Дата: 17.01.11
К этому нечего добавить


dmitriid.comGitHubLinkedIn
Re[34]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.01.11 14:40
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>>>>>Вообще-то, веб-программисты достаточно часто пользуются. Если от пользователя может прийти как «12,5» так и «12.5» в поле, то почти наверняка будет испольован коротенький регэксп типа /(\d+)(,|\.)*(\d+)*/. Который, при опыте, ничем не хуже, чем гипотетический [[Expr <- \d+ (,/.)* \d*]], который, кстати, нельзя применить прямо на месте и получить требуемые мне цифры/буквы.


G>>>>>>а replace(',','.'), который кстати гораздо очевиднее


M>>>>>Ну, я как пример


G>>>>Кстати касаемо PEG. С Peg можно без усилий написать парсер, который схавает множество форматов входной строки и выдаст число.


M>>>Зачем? То есть есть много задач, когда надо решить что-то среднее между банальным .replace'ом и полноценным парсером. PEG туда пока-то не помещается никак.


G>>А конкретнее про эти "много задач". Обычно задачи, которые решаются regexp, являются частями более общих задач.


M>Обычно «общие» задачи на практике даром не нужны Как в примере выше, ну не нужен мне парсер, который из каких-то там форматов перегоняет в цифры. У меня есть какие-то конкретных один-два формата, с которыми я работаю Обычно они спокойно ложатся в два-три регэкспа

А дальше что с этими форматами проиходит? вероятнее всего выполняется их парсинг и обработка уже в структурированной форме. Вот PEG поможет объединить парсинг и проверки с преобразованиями формата.

G>>Если несложно приведи примеры обратного.


M>есть у меня парсер мат. выражений на яваскрипте. уже готовый. переменные понимает и т.п. но не понимает проценты Имхо, было бы проще написать два выражения и снабдить их комментариями:

M>
M>/(.+)(\d)\s+(\d+)\%/           /* 10 + 20  50% */
M>/(.+)\s*(\+|-)\s*(\d+)\%/      /* 10 + 20 + 50% */
M>

M>чем вклиниваться в парсер и вообще

Ну ты же понимаешь что это костыли. Если такое требование не единично, то завтра тебе еще один костыль понадобится, а потом классика "проще выкинуть и написать заново, чем переделывать".
Technical Debt называется.

Кроме того PEG парсер, в отличие от табличных LR-парсеров, легко расширяется.

M>Да, я знаю, тут можно привести контрпример Но на данный момент это так и есть. Это кратко и емко уже описал Sinclair тут: http://rsdn.ru/forum/philosophy/4120092.1.aspx
Автор: Sinclair
Дата: 17.01.11
К этому нечего добавить

Тут другой вариант. Это regex, вводимые пользователем.
Re[35]: PEG vs RegExp
От: Mamut Швеция http://dmitriid.com
Дата: 25.01.11 21:09
Оценка:
M>>есть у меня парсер мат. выражений на яваскрипте. уже готовый. переменные понимает и т.п. но не понимает проценты Имхо, было бы проще написать два выражения и снабдить их комментариями:
M>>
M>>/(.+)(\d)\s+(\d+)\%/           /* 10 + 20  50% */
M>>/(.+)\s*(\+|-)\s*(\d+)\%/      /* 10 + 20 + 50% */
M>>

M>>чем вклиниваться в парсер и вообще

G>Ну ты же понимаешь что это костыли. Если такое требование не единично, то завтра тебе еще один костыль понадобится, а потом классика "проще выкинуть и написать заново, чем переделывать".


Таких костылей не так уж и много

G>Technical Debt называется.


G>Кроме того PEG парсер, в отличие от табличных LR-парсеров, легко расширяется.


Пока не появится легкий и быстрый аналог preg_match, никто не будет заморачиваться описанием грамматики и парсеров Вот как будет выглядеть пример выше на PEGе?

На самом деле — это повтор вопроса jazzer'а про правило для std:vector
Автор: jazzer
Дата: 20.01.11


M>>Да, я знаю, тут можно привести контрпример Но на данный момент это так и есть. Это кратко и емко уже описал Sinclair тут: http://rsdn.ru/forum/philosophy/4120092.1.aspx
Автор: Sinclair
Дата: 17.01.11
К этому нечего добавить

G>Тут другой вариант. Это regex, вводимые пользователем.

Это — стороны одной медали. Многое оттуда напрямую относится и к программистам.


dmitriid.comGitHubLinkedIn
Re[36]: PEG vs RegExp
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 25.01.11 22:20
Оценка:
M> Вот как будет выглядеть пример выше на PEGе?

синтаксис с пробелом я плохо понимаю, но вот если необходимо просто проценты добавить, то в штатной грамматике калькулятора необходимо будет лишь заменить number на percent-or-number
percent-or-number := percent / number;
percent := number '%';


M>На самом деле — это повтор вопроса jazzer'а про правило для std:vector
Автор: jazzer
Дата: 20.01.11


а в чем там проблема? где можно посмотреть полную постановку проблемы?
Re[37]: PEG vs RegExp
От: Mamut Швеция http://dmitriid.com
Дата: 26.01.11 05:31
Оценка:
DG>синтаксис с пробелом я плохо понимаю, но вот если необходимо просто проценты добавить, то в штатной грамматике калькулятора необходимо будет лишь заменить number на percent-or-number
DG>
DG>percent-or-number := percent / number;
DG>percent := number '%';
DG>


Там не все так просто Во что развернется этот пример?

В нашем случае у нас все эти проценты вводит человек. То есть, если у нас есть базовая цена x и есть наценки на нее. Задаются отдельно.

В итоге все это собирается банальным складыванием строк.

То есть если базовая цена 10, а оператор ввел +20 + 50%, то у нас получается строка "10 + 20 + 50%". Это должно развернуться в (10 + 20)*1.5.
Если оператор ввел просто 50%, то получается "10 50%", что должно развернуться в x*0.5.

С любыми любыми комбинациями. То есть + 2 + 3% + 5% — это (10+2)*1.03*1.05.

А если у нас x уже равен "1 — 5%", а оператор ввел наценку 50%? Это естественно превратится в "1 — 5% 50%", что должно развернуться в 1*1.05*0.5.

Два регэкспа спокойно решают эту проблему при наличии готового оператора

Да, я знаю, что у нас все мегакриво, но оно есть, что есть


M>>На самом деле — это повтор вопроса jazzer'а про правило для std:vector
Автор: jazzer
Дата: 20.01.11


DG>а в чем там проблема? где можно посмотреть полную постановку проблемы?


http://rsdn.ru/forum/philosophy/4120603.1.aspx
Автор: jazzer
Дата: 18.01.11


вот тебе простейший пример: "std::vector<(.+), std::allocator<\1>>".
Напиши такой в ПЕГе, сравним сложность.

/^std::vector<(.+), std::allocator<\1>>/



dmitriid.comGitHubLinkedIn
Re[35]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 26.01.11 05:48
Оценка:
Здравствуйте, gandjustas, Вы писали:

M>>Обычно «общие» задачи на практике даром не нужны Как в примере выше, ну не нужен мне парсер, который из каких-то там форматов перегоняет в цифры. У меня есть какие-то конкретных один-два формата, с которыми я работаю Обычно они спокойно ложатся в два-три регэкспа

G>А дальше что с этими форматами проиходит? вероятнее всего выполняется их парсинг и обработка уже в структурированной форме. Вот PEG поможет объединить парсинг и проверки с преобразованиями формата.

Гораздо чаще бывает так, что есть библиотека/компонент/приложение, умеющая делать нечто с данными конкретного формата (типа чисел с точками, а не с запятыми, или наоборот; как Excel в зависимости от локали, например).
И твоя задача заключается в том, чтоб привести данные, которые у тебя есть, к формату, который поймет библиотека.
Регэкспы замечательно с этой задачей справляются.

G>>>Если несложно приведи примеры обратного.


M>>есть у меня парсер мат. выражений на яваскрипте. уже готовый. переменные понимает и т.п. но не понимает проценты Имхо, было бы проще написать два выражения и снабдить их комментариями:

M>>
M>>/(.+)(\d)\s+(\d+)\%/           /* 10 + 20  50% */
M>>/(.+)\s*(\+|-)\s*(\d+)\%/      /* 10 + 20 + 50% */
M>>

M>>чем вклиниваться в парсер и вообще

G>Ну ты же понимаешь что это костыли. Если такое требование не единично, то завтра тебе еще один костыль понадобится, а потом классика "проще выкинуть и написать заново, чем переделывать".

G>Technical Debt называется.
кладешь регэксп в конфиг, и всего делов. А в приложении любая из имеющихся регэксповых библиотек возьмет этот регэксп и сделает все, что надо.
Понадобится что-то в регэкспе подправить или добавить — меняется только конфиг, перекомпилировать ничего не надо.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[38]: PEG vs RegExp
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 26.01.11 07:36
Оценка:
M>То есть если базовая цена 10, а оператор ввел +20 + 50%, то у нас получается строка "10 + 20 + 50%". Это должно развернуться в (10 + 20)*1.5.
M>Если оператор ввел просто 50%, то получается "10 50%", что должно развернуться в x*0.5.

M>С любыми любыми комбинациями. То есть + 2 + 3% + 5% — это (10+2)*1.03*1.05.


т.е. есть два постфиксных оператора: прибавить процент от выражения, и взять процент от выражения
приоритет ниже суммы/вычитания, вычисляется слева направо

так и пишем:

первое приближение (без учета вложенности и приоритетов)
percent-mul-expression := expression S+ percent;
percent-sum-expression := expression S* '+' S* percent;
sum-expression := expression S* sum-op S* expression;
mul-expression := expression S* mul-op S* expression;
number := [0-9]+;
percent := number '%';

sum-op := '+' / '-';
mul-op := '*' / '/';

S := ' ';


расставляем приоритеты:
expression := percent-expression;
percent-expression := sum-expression (percent-mul-operator / percent-sum-operator)*;
percent-mul-operator := S+ percent;
percent-sum-operator := S* '+' S* percent;
sum-expression := mul-expression (S* sum-op S* mul-expression)*;
mul-expression := other-expression (S* mul-op S* other-expression)*;
other-expression := ('(' expression ')') / number;

number := [0-9]+;
percent := number '%';

sum-op := '+' / '-';
mul-op := '*' / '/';

S := ' ';

навскидку будет конфликт: sum-expression применяется раньше, и имеет более общую форму, чем percent-sum-operator — воткнем предикат в sum-expression
без предиката до percent-expression будет доходить только хвостик в виде одно лишь знака '%'
expression := percent-expression;
percent-expression := sum-expression (percent-mul-operator / percent-sum-operator)*;
percent-mul-operator := S+ percent;
percent-sum-operator := S* '+' S* percent;
sum-expression := mul-expression (S* sum-op S*  !percent mul-expression)*;
mul-expression := other-expression (S* mul-op S* other-expression)*;
other-expression := ('(' expression ')') / number;

number := [0-9]+;
percent := number '%';

sum-op := '+' / '-';
mul-op := '*' / '/';

S := ' ';


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

M>вот тебе простейший пример: "std::vector<(.+), std::allocator<\1>>".

M>Напиши такой в ПЕГе, сравним сложность.

да, вспомнил. уже обсуждали эту тему с jazzer-ом, но это уже задача поиска, а не разбора.
сделать можно и прямо на пеге, сделаю, но позже
Re[36]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.01.11 08:02
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>есть у меня парсер мат. выражений на яваскрипте. уже готовый. переменные понимает и т.п. но не понимает проценты Имхо, было бы проще написать два выражения и снабдить их комментариями:

M>>>
M>>>/(.+)(\d)\s+(\d+)\%/           /* 10 + 20  50% */
M>>>/(.+)\s*(\+|-)\s*(\d+)\%/      /* 10 + 20 + 50% */
M>>>

M>>>чем вклиниваться в парсер и вообще

G>>Ну ты же понимаешь что это костыли. Если такое требование не единично, то завтра тебе еще один костыль понадобится, а потом классика "проще выкинуть и написать заново, чем переделывать".


M>Таких костылей не так уж и много

Но это все равно костыли.


M>Вот как будет выглядеть пример выше на PEGе?

Пример выше на peg будет выглядеть как парсер выражений на PEG, который легко расширить при необходимости.
Re[36]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.01.11 08:06
Оценка:
Здравствуйте, jazzer, Вы писали:

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


M>>>Обычно «общие» задачи на практике даром не нужны Как в примере выше, ну не нужен мне парсер, который из каких-то там форматов перегоняет в цифры. У меня есть какие-то конкретных один-два формата, с которыми я работаю Обычно они спокойно ложатся в два-три регэкспа

G>>А дальше что с этими форматами проиходит? вероятнее всего выполняется их парсинг и обработка уже в структурированной форме. Вот PEG поможет объединить парсинг и проверки с преобразованиями формата.

J>Гораздо чаще бывает так, что есть библиотека/компонент/приложение, умеющая делать нечто с данными конкретного формата (типа чисел с точками, а не с запятыми, или наоборот; как Excel в зависимости от локали, например).

J>И твоя задача заключается в том, чтоб привести данные, которые у тебя есть, к формату, который поймет библиотека.
J>Регэкспы замечательно с этой задачей справляются.
Еще раз повторю. Надо взглянуть на проблему по-другому. Скармливать библиотеке не текст, а структуры, которые из текста парсятся другими средствами, нарпимер PEG.

J>кладешь регэксп в конфиг, и всего делов. А в приложении любая из имеющихся регэксповых библиотек возьмет этот регэксп и сделает все, что надо.

J>Понадобится что-то в регэкспе подправить или добавить — меняется только конфиг, перекомпилировать ничего не надо.
Я посмотрел по своим проектам — 99% регулярных выражений статичны и являются частью БЛ, поэтому вносить их в конфиг смысла нет, гораздо выгоднее их компилировать на этапе компиляции программы. Вот только далеко не все так умеют.
Re[39]: PEG vs RegExp
От: Mamut Швеция http://dmitriid.com
Дата: 26.01.11 08:09
Оценка:
Здравствуйте, DarkGray, Вы писали:

M>>То есть если базовая цена 10, а оператор ввел +20 + 50%, то у нас получается строка "10 + 20 + 50%". Это должно развернуться в (10 + 20)*1.5.

M>>Если оператор ввел просто 50%, то получается "10 50%", что должно развернуться в x*0.5.

M>>С любыми любыми комбинациями. То есть + 2 + 3% + 5% — это (10+2)*1.03*1.05.


DG>т.е. есть два постфиксных оператора: прибавить процент от выражения, и взять процент от выражения

DG>приоритет ниже суммы/вычитания, вычисляется слева направо

DG>так и пишем:


skip

DG>расскрываться все будет в дерево, где на одном уровне будут операторы одного приоритета.


Это все хоршо, но нафига козе баян, если залдача решается за пару минут двумя регэкспами? Даже если калькулятор уже написан с использованием PEG'а.

M>>вот тебе простейший пример: "std::vector<(.+), std::allocator<\1>>".

M>>Напиши такой в ПЕГе, сравним сложность.

DG>да, вспомнил. уже обсуждали эту тему с jazzer-ом, но это уже задача поиска, а не разбора.

DG>сделать можно и прямо на пеге, сделаю, но позже

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


dmitriid.comGitHubLinkedIn
Re[40]: PEG vs RegExp
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 26.01.11 10:28
Оценка:
M>Ну, вообще-то, регулярки постоянно для этого и используются — найти и заменить. Даже мой пример с процентами, по сути, к этому и сводится — найти и заменить.

удобнее считать, что есть две разные задачи: распарсить текст -> дерево, преобразовать одно дерево в другое.
первое удобнее делается на peg-е,
второе удобнее делается на ФЯ.

если использовать regex, то тогда решается задача текст преобразовать в другой текст, что приводит и к сложному коду, и к скрытым ошибкам, и к лишним оверхедам.
Re[37]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 26.01.11 12:09
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>Гораздо чаще бывает так, что есть библиотека/компонент/приложение, умеющая делать нечто с данными конкретного формата (типа чисел с точками, а не с запятыми, или наоборот; как Excel в зависимости от локали, например).

J>>И твоя задача заключается в том, чтоб привести данные, которые у тебя есть, к формату, который поймет библиотека.
J>>Регэкспы замечательно с этой задачей справляются.
G>Еще раз повторю. Надо взглянуть на проблему по-другому. Скармливать библиотеке не текст, а структуры, которые из текста парсятся другими средствами, нарпимер PEG.
Ну во-первых, для этого библиотека должна иметь соответствующий интерфейс, которого у нее может и не быть. Пример — эксель.
Во-вторых, ты фактически предлагаешь заново реализовать парсинг своими силами, хотя он уже реализован в библиотеке.
В-третьих, там бог знает какой формат может быть у файла, и библиотека о нем знает, а тебе и надо-то всего что запятые на точки в плавающих числах поменять, потому что файл генерится другой программой в другой локали...

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

J>>кладешь регэксп в конфиг, и всего делов. А в приложении любая из имеющихся регэксповых библиотек возьмет этот регэксп и сделает все, что надо.

J>>Понадобится что-то в регэкспе подправить или добавить — меняется только конфиг, перекомпилировать ничего не надо.
G>Я посмотрел по своим проектам — 99% регулярных выражений статичны и являются частью БЛ, поэтому вносить их в конфиг смысла нет, гораздо выгоднее их компилировать на этапе компиляции программы. Вот только далеко не все так умеют.
Ну а я посмотрел по своим — все регэкспы в конфигах, потому что их иногда надо подкручивать, и перекомпилировать всю программу — нафиг надо. Что я делаю не так?
Более того, вот сейчас эти твои статичные регэкспы являются узким местом в плане производительности? Маловероятно, но если вдруг да, то какой их процент таков, и на сколько ускорится программа, если переписать их на ПЕГ?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[37]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 26.01.11 12:26
Оценка:
Здравствуйте, gandjustas, Вы писали:

M>>Таких костылей не так уж и много

G>Но это все равно костыли.
Половина работы программиста — это вытесывание костылей.

M>>Вот как будет выглядеть пример выше на PEGе?

G>Пример выше на peg будет выглядеть как парсер выражений на PEG, который легко расширить при необходимости.
Короче, ПЕГ — это такой вирус. Если уже есть что-то на ПЕГе, до изменить/добавить что-то в грамматику сравнительно легко.
А если нет — придется реализовать все на ПЕГе самому

Ну или за полминуты написать регэксп и перейти к выпеканию следующего костыля
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[38]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.01.11 12:31
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>>>Гораздо чаще бывает так, что есть библиотека/компонент/приложение, умеющая делать нечто с данными конкретного формата (типа чисел с точками, а не с запятыми, или наоборот; как Excel в зависимости от локали, например).

J>>>И твоя задача заключается в том, чтоб привести данные, которые у тебя есть, к формату, который поймет библиотека.
J>>>Регэкспы замечательно с этой задачей справляются.
G>>Еще раз повторю. Надо взглянуть на проблему по-другому. Скармливать библиотеке не текст, а структуры, которые из текста парсятся другими средствами, нарпимер PEG.
J>Ну во-первых, для этого библиотека должна иметь соответствующий интерфейс, которого у нее может и не быть. Пример — эксель.
J>Во-вторых, ты фактически предлагаешь заново реализовать парсинг своими силами, хотя он уже реализован в библиотеке.
J>В-третьих, там бог знает какой формат может быть у файла, и библиотека о нем знает, а тебе и надо-то всего что запятые на точки в плавающих числах поменять, потому что файл генерится другой программой в другой локали...
Странно, почему всегда сводится к тому что "уже есть что-то что никак нельзя менять"?
Если не рассматривать такие, вообще говоря паталогические, случаи найдутся у regexp преимущества?
Пока нашли только два:
1)Большая известность, распространенность и "изучаемость"
2)Как следствие 1) — возможность писать regex для непрограммистов.


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

Не надо эмоциональных оценок, от них веет непрофессионализмом.
А regexp не надо писать и отлаживать?
Я вот в haskell отлично использую parsec вместо regexp, хотя c синтаксисом regexp знаком гораздо больше. Выходит примерно одинаково, только комбинаторы parsec еще и при компиляции проверяются.

J>>>кладешь регэксп в конфиг, и всего делов. А в приложении любая из имеющихся регэксповых библиотек возьмет этот регэксп и сделает все, что надо.

J>>>Понадобится что-то в регэкспе подправить или добавить — меняется только конфиг, перекомпилировать ничего не надо.
G>>Я посмотрел по своим проектам — 99% регулярных выражений статичны и являются частью БЛ, поэтому вносить их в конфиг смысла нет, гораздо выгоднее их компилировать на этапе компиляции программы. Вот только далеко не все так умеют.
J>Ну а я посмотрел по своим — все регэкспы в конфигах, потому что их иногда надо подкручивать, и перекомпилировать всю программу — нафиг надо. Что я делаю не так?
А на каком языке ты пишешь?

J>Более того, вот сейчас эти твои статичные регэкспы являются узким местом в плане производительности? Маловероятно, но если вдруг да, то какой их процент таков, и на сколько ускорится программа, если переписать их на ПЕГ?

PEG, как и Regexp — нотации, надо к конкретным реализациям обращаться. Например большинство реализация не парятся с приведением к ДКА для regexp, поэтому для сложных regexp будет работать примерно одинаково по скорости с наивной реализацией peg, например на комбинаторах.
Re[38]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.01.11 12:37
Оценка:
Здравствуйте, jazzer, Вы писали:

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


M>>>Таких костылей не так уж и много

G>>Но это все равно костыли.
J>Половина работы программиста — это вытесывание костылей.
А другая половина — обход костылей других программистов.
И только малая часть работы идет на создание чего-то послезного. Вот и предлагается улучшить.

M>>>Вот как будет выглядеть пример выше на PEGе?

G>>Пример выше на peg будет выглядеть как парсер выражений на PEG, который легко расширить при необходимости.
J>Короче, ПЕГ — это такой вирус. Если уже есть что-то на ПЕГе, до изменить/добавить что-то в грамматику сравнительно легко.
PEG нотация, в отличие от Regexp поддерживает декомпозицию. Для сложных regexp типа email это будет особенно заметно.

J>А если нет — придется реализовать все на ПЕГе самому

Так тебе в любом случае нужет будет парсер. Чем его делать собираешься?

J>Ну или за полминуты написать регэксп и перейти к выпеканию следующего костыля

А что мешает научиться писать за полминуты парсинг на PEG?
Re[39]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 26.01.11 12:51
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


G>Странно, почему всегда сводится к тому что "уже есть что-то что никак нельзя менять"?

G>Если не рассматривать такие, вообще говоря паталогические, случаи найдутся у regexp преимущества?
Что-то мне подозрительно много патологических случаев попадается. Эксель в их числе, кстати.

G>Пока нашли только два:

G>1)Большая известность, распространенность и "изучаемость"
G>2)Как следствие 1) — возможность писать regex для непрограммистов.
и для программистов тоже, почему только для непрограммистов-то?
Я, когда запускаю поиск по логам, замечательно обхожусь регэкспами и мне до сих пор не приходилось столкнуться с задачей, чтоб надо было что-то найти, и регэкспы с этим не справились бы (настолько, что пришлось бы писать полноценную грамматику на ПЕГа или на чем угодно еще) или непозволительно тормозили.
Ну и
3) обилие отточенного инструментария. Из которого перл на первом месте, естественно.
Все это сводит нынешние применения регэкспов (мною, по крайней мере) к настолько простой операции, для которой хватает спинного мозга, что даже и мысли не шевелится подумать над грамматикой или о чем-то в этом роде.

Естественно, это не относится к случаям, когда надо именно что-то распарсить как положено — тут я, конечно же, буду строить полноценный парсер, а не лепить регэкспы.

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

G>Не надо эмоциональных оценок, от них веет непрофессионализмом.
А где тут эмоциональные оценки? Тебе показывают элементарный регэксп на 15 символов, а ты говоришь, что надо целиком парсер арифметики реализовать

G>А regexp не надо писать и отлаживать?

В 99% — нет (у меня, по крайней мере). Для оставшегося надо честный парсер писать.
Плюс я регэксп всегда могу на перле потестить, это минутное дело. А потом скормить Boost.Regex и прочим (JavaScript, C#) как есть — они все совместимы с перловыми регэкспами.

G>Я вот в haskell отлично использую parsec вместо regexp, хотя c синтаксисом regexp знаком гораздо больше. Выходит примерно одинаково, только комбинаторы parsec еще и при компиляции проверяются.

Эти проверки (парность скобок? что там еще можно проверить?) — о-малое от правильности регэкспа.

G>А на каком языке ты пишешь?

С++. Использую Boost.Regex для регэкспов (Boost.Xpressive для регэкспов времени компиляции, но это экзотика) и Boost.Spirit для полноценного парсинга (который реализует ПЕГ, кстати сказать). И не смешиваю эти две области.
А по логам шарюсь перлом — большего не надо для однострочников, ПЕГ тут явным оверкиллом будет.

J>>Более того, вот сейчас эти твои статичные регэкспы являются узким местом в плане производительности? Маловероятно, но если вдруг да, то какой их процент таков, и на сколько ускорится программа, если переписать их на ПЕГ?

G>PEG, как и Regexp — нотации, надо к конкретным реализациям обращаться. Например большинство реализация не парятся с приведением к ДКА для regexp, поэтому для сложных regexp будет работать примерно одинаково по скорости с наивной реализацией peg, например на комбинаторах.
Это все понятно, я не о сферической нотации в вакууме, а о тех регэкспах, о которых ты говорил, которые у тебя в твоей программе. Насколько критично их ускорять? Только честно.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[40]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.01.11 13:21
Оценка:
Здравствуйте, jazzer, Вы писали:

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


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


G>>Странно, почему всегда сводится к тому что "уже есть что-то что никак нельзя менять"?

G>>Если не рассматривать такие, вообще говоря паталогические, случаи найдутся у regexp преимущества?
J>Что-то мне подозрительно много патологических случаев попадается. Эксель в их числе, кстати.
не повезло.

G>>Пока нашли только два:

G>>1)Большая известность, распространенность и "изучаемость"
G>>2)Как следствие 1) — возможность писать regex для непрограммистов.
J>и для программистов тоже, почему только для непрограммистов-то?
Потому что программистам можно писать код.

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

Ясное дело что ты не пользуешься PEG, потому что не пользуешься PEG.

J>3) обилие отточенного инструментария. Из которого перл на первом месте, естественно.

J>Все это сводит нынешние применения регэкспов (мною, по крайней мере) к настолько простой операции, для которой хватает спинного мозга, что даже и мысли не шевелится подумать над грамматикой или о чем-то в этом роде.
Странная мысль. Regexp — тоже грамматика, но её ты пишешь не задумываясь. Что мешает изучить peg чтобы также не задумываясь писать парсеры?

J>Естественно, это не относится к случаям, когда надо именно что-то распарсить как положено — тут я, конечно же, буду строить полноценный парсер, а не лепить регэкспы.

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

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

G>>Не надо эмоциональных оценок, от них веет непрофессионализмом.
J>А где тут эмоциональные оценки? Тебе показывают элементарный регэксп на 15 символов, а ты говоришь, что надо целиком парсер арифметики реализовать
Так тебе в любом случае нужен парсер выражений. Ты кого обмануть пытаешься?

G>>А regexp не надо писать и отлаживать?

J>В 99% — нет (у меня, по крайней мере). Для оставшегося надо честный парсер писать.
J>Плюс я регэксп всегда могу на перле потестить, это минутное дело. А потом скормить Boost.Regex и прочим (JavaScript, C#) как есть — они все совместимы с перловыми регэкспами.
Опять-таки ты предполагаешь что написание парсера — сложное дело. Parsec вполне опровергает твою точку зрения.

G>>Я вот в haskell отлично использую parsec вместо regexp, хотя c синтаксисом regexp знаком гораздо больше. Выходит примерно одинаково, только комбинаторы parsec еще и при компиляции проверяются.

J>Эти проверки (парность скобок? что там еще можно проверить?) — о-малое от правильности регэкспа.
А я вот часто попадаюсь на сочетании эскейпинга в regexp и эскейпинга в строках в самом языке.

G>>А на каком языке ты пишешь?

J>С++. Использую Boost.Regex для регэкспов (Boost.Xpressive для регэкспов времени компиляции, но это экзотика) и Boost.Spirit для полноценного парсинга (который реализует ПЕГ, кстати сказать). И не смешиваю эти две области.
J>А по логам шарюсь перлом — большего не надо для однострочников, ПЕГ тут явным оверкиллом будет.
там где хватает одной строки regexp хватит и одной строки peg.

J>>>Более того, вот сейчас эти твои статичные регэкспы являются узким местом в плане производительности? Маловероятно, но если вдруг да, то какой их процент таков, и на сколько ускорится программа, если переписать их на ПЕГ?

G>>PEG, как и Regexp — нотации, надо к конкретным реализациям обращаться. Например большинство реализация не парятся с приведением к ДКА для regexp, поэтому для сложных regexp будет работать примерно одинаково по скорости с наивной реализацией peg, например на комбинаторах.
J>Это все понятно, я не о сферической нотации в вакууме, а о тех регэкспах, о которых ты говорил, которые у тебя в твоей программе. Насколько критично их ускорять? Только честно.
хз, я вообще не парился по поводу производительности регэкспов, мне даже мерить лень.
Re[39]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 26.01.11 13:58
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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


M>>>>Таких костылей не так уж и много

G>>>Но это все равно костыли.
J>>Половина работы программиста — это вытесывание костылей.
G>А другая половина — обход костылей других программистов.
G>И только малая часть работы идет на создание чего-то послезного. Вот и предлагается улучшить.
Так костыли все равно никуда не денутся, без них не взлетит
Я к том, что если что-то — костыли, то это еще не значит, что это плохо или не нужно.
Просто костыли объективно необходимы, мир так устроен.

M>>>>Вот как будет выглядеть пример выше на PEGе?

G>>>Пример выше на peg будет выглядеть как парсер выражений на PEG, который легко расширить при необходимости.
J>>Короче, ПЕГ — это такой вирус. Если уже есть что-то на ПЕГе, до изменить/добавить что-то в грамматику сравнительно легко.
G>PEG нотация, в отличие от Regexp поддерживает декомпозицию. Для сложных regexp типа email это будет особенно заметно.
регэкспы — это строчки. Думаю, ни у кого нет проблем с композицией строчек
А сложные стандартные регэкспы типа email уже написаны и обычно вообще упрятаны в библиотеки.
Я вот честно сомневаюсь, что ты, чтоб проверить e-mail, начнешь читать RFC822 и аккуратно реализовывать его в ПЕГе.
Наверняка же возьмешь что-то готовое, и тебе начхать будет, регэкспы там внутри, ПЕГи или гномик с лупой.

Не говоря уже о том, что это обычно оверкилл и для валидации достаточно чего-то простого, по причинам:

First, not all RFC-valid address are deliverable. For example, foo@foo.foo.foo.foo is valid in form, but in practice is not deliverable. Some people try to do DNS lookups for MX records, even trying to connect to the host handling that address's mail to check if it's valid at that site. This is a poor approach because most sites can't do a direct connect to any other site, and even if they could, mail receiving sites increasingly either ignore the SMTP VRFY command or fib about its answer.

Second, some RFC-invalid addresses, in practice, are perfectly deliverable. For example, a lone postmaster is almost certainly deliverable but doesn't pass RFC-822 muster. It doesn't have an @ in it.

Thirdly and most important, just because the address happens to be both valid and deliverable doesn't mean that it's the right one. president@whitehouse.gov , for example, is valid by the RFC and deliverable. But it's very unlikely that would really be the mail address of the person submitting information to your CGI script.

Но это уже офтопик, хотя и показательный.

J>>А если нет — придется реализовать все на ПЕГе самому

G>Так тебе в любом случае нужет будет парсер. Чем его делать собираешься?
С чего бы мне "в любом случае" "нужен" будет парсер?
Там, где я пользуюсь регэкспами, мне парсер нафиг не нужен.

J>>Ну или за полминуты написать регэксп и перейти к выпеканию следующего костыля

G>А что мешает научиться писать за полминуты парсинг на PEG?
Ничего не мешает, что там учить. ПЕГ банально многословнее. Не в последнюю очередь из-за ограниченности синтаксиса ПЕГа. Не говоря уже о том, что некоторые базовые вещи регэкспов (типа обратных ссылок, синтаксиса замены, регулировки жадности кванторов) в ПЕГе попросту отсутствуют.
Но это не делает ПЕГ хуже, пока ПЕГ не пытается соревноваться с регэкспами на их поле, просто потому что ПЕГ для других задач делался, которые с регэкспами не особо пересекаются.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[41]: PEG vs RegExp
От: Mamut Швеция http://dmitriid.com
Дата: 26.01.11 14:10
Оценка:
M>>Ну, вообще-то, регулярки постоянно для этого и используются — найти и заменить. Даже мой пример с процентами, по сути, к этому и сводится — найти и заменить.

DG>удобнее считать, что есть две разные задачи: распарсить текст -> дерево, преобразовать одно дерево в другое.

DG>первое удобнее делается на peg-е,
DG>второе удобнее делается на ФЯ.

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


Ну так а что делать, если альтернатив нет?


dmitriid.comGitHubLinkedIn
Re[41]: PEG vs RegExp
От: Mamut Швеция http://dmitriid.com
Дата: 26.01.11 14:16
Оценка:
J>>>>В общем, то, что делается регэкспом за полминуты (полное рабочее решение), ты фактически предлагаешь заменить парсящим монстром, который еще писать и отлаживать. Выгоды как-то неочевидны.
G>>>Не надо эмоциональных оценок, от них веет непрофессионализмом.
J>>А где тут эмоциональные оценки? Тебе показывают элементарный регэксп на 15 символов, а ты говоришь, что надо целиком парсер арифметики реализовать
G>Так тебе в любом случае нужен парсер выражений. Ты кого обмануть пытаешься?

Ты как-то упустил момент, что парсер уже есть. И мне лениво лезть в его код. Потому что этот «простейший пример, с которым легко справится PEG» тут
Автор: DarkGray
Дата: 26.01.11
в процессе расширения потенциально вызывает необходимость переписывать и сам парсер тоже.

А так — preg_replace и заменил, что тебе надо на что тебе надо.


dmitriid.comGitHubLinkedIn
Re[40]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.01.11 14:25
Оценка: 1 (1)
Здравствуйте, jazzer, Вы писали:

M>>>>>Вот как будет выглядеть пример выше на PEGе?

G>>>>Пример выше на peg будет выглядеть как парсер выражений на PEG, который легко расширить при необходимости.
J>>>Короче, ПЕГ — это такой вирус. Если уже есть что-то на ПЕГе, до изменить/добавить что-то в грамматику сравнительно легко.
G>>PEG нотация, в отличие от Regexp поддерживает декомпозицию. Для сложных regexp типа email это будет особенно заметно.
J>регэкспы — это строчки. Думаю, ни у кого нет проблем с композицией строчек
Да, примерно также как SQL — строка, но композиция SQL склейкой строк — крайне сложное занятие.

J>>>А если нет — придется реализовать все на ПЕГе самому

G>>Так тебе в любом случае нужет будет парсер. Чем его делать собираешься?
J>С чего бы мне "в любом случае" "нужен" будет парсер?
Для исходной задачи с парсингом выражения.

J>Там, где я пользуюсь регэкспами, мне парсер нафиг не нужен.

Regexp и есть парсер, только он не выполняет построение "дерева разбора". Хотя для замены — выполняет что-то подобное, но далеко внутри.

J>>>Ну или за полминуты написать регэксп и перейти к выпеканию следующего костыля

G>>А что мешает научиться писать за полминуты парсинг на PEG?

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

J>Но это не делает ПЕГ хуже, пока ПЕГ не пытается соревноваться с регэкспами на их поле, просто потому что ПЕГ для других задач делался, которые с регэкспами не особо пересекаются.
Область применения регэкспов сильно зависит от языка. Например в перле даже округление числе делается иногда регэкспами, а в haskell большинство задач парсинга делается parsec не задумываясь.
Re[41]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 27.01.11 08:43
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Странно, почему всегда сводится к тому что "уже есть что-то что никак нельзя менять"?

G>>>Если не рассматривать такие, вообще говоря паталогические, случаи найдутся у regexp преимущества?
J>>Что-то мне подозрительно много патологических случаев попадается. Эксель в их числе, кстати.
G>не повезло.
С Экселем, боюсь, всем не повезло.
Мамуту вон тоже не повезло — у него библиотека, сволочь такая, УЖЕ умеет парсить.
Не говоря уж о тех, кому страшно не повезло со всякими MSXML и т.п., которые, вот незадача, принимают текст на вход.

J>>и для программистов тоже, почему только для непрограммистов-то?

G>Потому что программистам можно писать код.
А зачем им писать код, когда можно не писать?

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

G>Ясное дело что ты не пользуешься PEG, потому что не пользуешься PEG.
Т.е. ты по логам шаришься ПЕГом?

J>>3) обилие отточенного инструментария. Из которого перл на первом месте, естественно.

J>>Все это сводит нынешние применения регэкспов (мною, по крайней мере) к настолько простой операции, для которой хватает спинного мозга, что даже и мысли не шевелится подумать над грамматикой или о чем-то в этом роде.
G>Странная мысль. Regexp — тоже грамматика, но её ты пишешь не задумываясь. Что мешает изучить peg чтобы также не задумываясь писать парсеры?
ты смешиваешь грамматику регэкспа/пега и грамматику текста, на который мы его собираемся напустить.
Регэкспу пофиг на грамматику текста. А ПЕГ как раз ее и описывает, для этого ты ее должен, по крайней мере, понимать.

J>>Естественно, это не относится к случаям, когда надо именно что-то распарсить как положено — тут я, конечно же, буду строить полноценный парсер, а не лепить регэкспы.

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

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

G>>>Не надо эмоциональных оценок, от них веет непрофессионализмом.
J>>А где тут эмоциональные оценки? Тебе показывают элементарный регэксп на 15 символов, а ты говоришь, что надо целиком парсер арифметики реализовать
G>Так тебе в любом случае нужен парсер выражений. Ты кого обмануть пытаешься?
Не нужен, он уже есть. А мне всего лишь нужно слегка подкрутить текст, который я ему отдаю на вход.

G>>>А regexp не надо писать и отлаживать?

J>>В 99% — нет (у меня, по крайней мере). Для оставшегося надо честный парсер писать.
J>>Плюс я регэксп всегда могу на перле потестить, это минутное дело. А потом скормить Boost.Regex и прочим (JavaScript, C#) как есть — они все совместимы с перловыми регэкспами.
G>Опять-таки ты предполагаешь что написание парсера — сложное дело. Parsec вполне опровергает твою точку зрения.
парсек в какой части меня опровергает? Он доступен в JavaScript/C# и т.д? Можно одно и то же ПЕГ-выражение скормить разным приложениям или языкам? Его можно потестить на ЛУА, а потом отдать в парсек? Я пока что не вижу преимуществ ПЕГа перед регэкспами в плане удобства использования.

G>>>Я вот в haskell отлично использую parsec вместо regexp, хотя c синтаксисом regexp знаком гораздо больше. Выходит примерно одинаково, только комбинаторы parsec еще и при компиляции проверяются.

J>>Эти проверки (парность скобок? что там еще можно проверить?) — о-малое от правильности регэкспа.
G>А я вот часто попадаюсь на сочетании эскейпинга в regexp и эскейпинга в строках в самом языке.
Бывает.

J>>А по логам шарюсь перлом — большего не надо для однострочников, ПЕГ тут явным оверкиллом будет.

G>там где хватает одной строки regexp хватит и одной строки peg.
как у нас в ПЕГе насчет обратных ссылок и прочего?

J>>Это все понятно, я не о сферической нотации в вакууме, а о тех регэкспах, о которых ты говорил, которые у тебя в твоей программе. Насколько критично их ускорять? Только честно.

G>хз, я вообще не парился по поводу производительности регэкспов, мне даже мерить лень.
Ну а к чему тогда все эти разговоры про то, что можно было бы твои регэкспы переписать на ПЕГ и компилировать в статике? Именно те регэкспы, которые у тебя в твоей программе?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[41]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 27.01.11 08:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>PEG нотация, в отличие от Regexp поддерживает декомпозицию. Для сложных regexp типа email это будет особенно заметно.

J>>регэкспы — это строчки. Думаю, ни у кого нет проблем с композицией строчек
G>Да, примерно также как SQL — строка, но композиция SQL склейкой строк — крайне сложное занятие.
Прямо так уж и "крайне сложное"?
Я вот как-то в админе в основном копи-пейстом запросы составляю, и ничего. Та же склейка строк

G>>>Так тебе в любом случае нужет будет парсер. Чем его делать собираешься?

J>>С чего бы мне "в любом случае" "нужен" будет парсер?
G>Для исходной задачи с парсингом выражения.
В исходной задаче парсер уже есть, надо только вход для него подкрутить. Уже раз 20 это было сказано.

J>>Там, где я пользуюсь регэкспами, мне парсер нафиг не нужен.

G>Regexp и есть парсер, только он не выполняет построение "дерева разбора". Хотя для замены — выполняет что-то подобное, но далеко внутри.
ну так этот парсер уже реализован за меня, а на ПЕГе мне придется написать его самому.

J>>>>Ну или за полминуты написать регэксп и перейти к выпеканию следующего костыля

G>>>А что мешает научиться писать за полминуты парсинг на PEG?
Так в следующем предложении и сказано же...

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

J>>Но это не делает ПЕГ хуже, пока ПЕГ не пытается соревноваться с регэкспами на их поле, просто потому что ПЕГ для других задач делался, которые с регэкспами не особо пересекаются.
G>Область применения регэкспов сильно зависит от языка. Например в перле даже округление числе делается иногда регэкспами, а в haskell большинство задач парсинга делается parsec не задумываясь.
Я так и думал, что вопрос насчет недостатка фич возражений не вызовет.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[41]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 27.01.11 08:54
Оценка:
Здравствуйте, DarkGray, Вы писали:


M>>Ну, вообще-то, регулярки постоянно для этого и используются — найти и заменить. Даже мой пример с процентами, по сути, к этому и сводится — найти и заменить.


DG>удобнее считать, что есть две разные задачи: распарсить текст -> дерево, преобразовать одно дерево в другое.

DG>первое удобнее делается на peg-е,
DG>второе удобнее делается на ФЯ.

Еще есть третья задача — все то же самое, но нет никакого дерева Или даже есть, но тебе на него пофиг И вот тут регэкспы рулят
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[42]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.01.11 09:03
Оценка:
Здравствуйте, jazzer, Вы писали:

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


G>>>>Странно, почему всегда сводится к тому что "уже есть что-то что никак нельзя менять"?

G>>>>Если не рассматривать такие, вообще говоря паталогические, случаи найдутся у regexp преимущества?
J>>>Что-то мне подозрительно много патологических случаев попадается. Эксель в их числе, кстати.
G>>не повезло.
J>С Экселем, боюсь, всем не повезло.
J>Мамуту вон тоже не повезло — у него библиотека, сволочь такая, УЖЕ умеет парсить.
J>Не говоря уж о тех, кому страшно не повезло со всякими MSXML и т.п., которые, вот незадача, принимают текст на вход.
И что? Это значит что и в дальнейшем надо ориентироваться на то что кто-то уже написал парсер и придумывать к нему костыли?

J>>>и для программистов тоже, почему только для непрограммистов-то?

G>>Потому что программистам можно писать код.
J>А зачем им писать код, когда можно не писать?
Потому что многие вещи можно делать и без regexp, причем более очевидными способами. Типа замены запятых на точки.

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

G>>Ясное дело что ты не пользуешься PEG, потому что не пользуешься PEG.
J>Т.е. ты по логам шаришься ПЕГом?
Я по логам обычно шарюсь готовыми утилитами или текстовым поиском.

J>>>3) обилие отточенного инструментария. Из которого перл на первом месте, естественно.

J>>>Все это сводит нынешние применения регэкспов (мною, по крайней мере) к настолько простой операции, для которой хватает спинного мозга, что даже и мысли не шевелится подумать над грамматикой или о чем-то в этом роде.
G>>Странная мысль. Regexp — тоже грамматика, но её ты пишешь не задумываясь. Что мешает изучить peg чтобы также не задумываясь писать парсеры?
J>ты смешиваешь грамматику регэкспа/пега и грамматику текста, на который мы его собираемся напустить.
J>Регэкспу пофиг на грамматику текста. А ПЕГ как раз ее и описывает, для этого ты ее должен, по крайней мере, понимать.
Regexp тоже описывает грамматику, причем вполне определенного вида.

J>>>Естественно, это не относится к случаям, когда надо именно что-то распарсить как положено — тут я, конечно же, буду строить полноценный парсер, а не лепить регэкспы.

G>>Это потому что ты неявно считаешь написание парсера сложной задачей, хотя во многих случаях нужны парсеры не сложнее regexp для email.
G>>Кроме того с PEG можно комбинировать парсеры между собой.
J>так же, как и регэкспы.
Покажи.
Особо инересен случай когда клеите regex такого вида: (re1 И НЕ re2)

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

G>>>>Не надо эмоциональных оценок, от них веет непрофессионализмом.
J>>>А где тут эмоциональные оценки? Тебе показывают элементарный регэксп на 15 символов, а ты говоришь, что надо целиком парсер арифметики реализовать
G>>Так тебе в любом случае нужен парсер выражений. Ты кого обмануть пытаешься?
J>Не нужен, он уже есть. А мне всего лишь нужно слегка подкрутить текст, который я ему отдаю на вход.
И что? Ты и в дельнейшем будешь всегда ориентировать на то что парсер уже есть, а тебе надо "лишь нужно слегка подкрутить текст"?

G>>>>А regexp не надо писать и отлаживать?

J>>>В 99% — нет (у меня, по крайней мере). Для оставшегося надо честный парсер писать.
J>>>Плюс я регэксп всегда могу на перле потестить, это минутное дело. А потом скормить Boost.Regex и прочим (JavaScript, C#) как есть — они все совместимы с перловыми регэкспами.
G>>Опять-таки ты предполагаешь что написание парсера — сложное дело. Parsec вполне опровергает твою точку зрения.
J>парсек в какой части меня опровергает? Он доступен в JavaScript/C# и т.д? Можно одно и то же ПЕГ-выражение скормить разным приложениям или языкам? Его можно потестить на ЛУА, а потом отдать в парсек? Я пока что не вижу преимуществ ПЕГа перед регэкспами в плане удобства использования.
Еще раз. Ты неявно считаешь что написание PEG сложнее regex, а все остальное уже является следствием такого суждения.
У haskell есть repl, которым ты очень быстро можешь протестить парсер

J>>>А по логам шарюсь перлом — большего не надо для однострочников, ПЕГ тут явным оверкиллом будет.

G>>там где хватает одной строки regexp хватит и одной строки peg.
J>как у нас в ПЕГе насчет обратных ссылок и прочего?
Да там вообще такого говна нет, у него есть более полезные примитивы, а еще в правильном парсере есть вывод правила, в котором мы можем сказать fail для любого неустраиваюего нас выражения.


J>>>Это все понятно, я не о сферической нотации в вакууме, а о тех регэкспах, о которых ты говорил, которые у тебя в твоей программе. Насколько критично их ускорять? Только честно.

G>>хз, я вообще не парился по поводу производительности регэкспов, мне даже мерить лень.
J>Ну а к чему тогда все эти разговоры про то, что можно было бы твои регэкспы переписать на ПЕГ и компилировать в статике? Именно те регэкспы, которые у тебя в твоей программе?
К тому что компиляция PEG (или любого другого парсера) в compile-time дает больше простора для оптимизиции, тупо по времени. Если будет в рантайме компилироваться в течение 20 секунд, то все пошлют нах такой инструмент.
Re[42]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.01.11 09:11
Оценка:
Здравствуйте, jazzer, Вы писали:

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


G>>>>PEG нотация, в отличие от Regexp поддерживает декомпозицию. Для сложных regexp типа email это будет особенно заметно.

J>>>регэкспы — это строчки. Думаю, ни у кого нет проблем с композицией строчек
G>>Да, примерно также как SQL — строка, но композиция SQL склейкой строк — крайне сложное занятие.
J>Прямо так уж и "крайне сложное"?
Именно.

J>Я вот как-то в админе в основном копи-пейстом запросы составляю, и ничего. Та же склейка строк

Данивопрос. Вот у тебя есть запрос в виде текста, возможно как-то побитый на части. внезапно тебе понадобилось добавить туда еще один джоин и условия фильтрации на поля этой таблицы. Попробуй написать такой код, который позволяет произвольно выполнять такие действия и при этом гарантировать корректность получившегося SQL.
Re[43]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 27.01.11 09:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>Не говоря уж о тех, кому страшно не повезло со всякими MSXML и т.п., которые, вот незадача, принимают текст на вход.

G>И что? Это значит что и в дальнейшем надо ориентироваться на то что кто-то уже написал парсер и придумывать к нему костыли?
Естественно.
А что, кто-то в здравом уме начнет переписывать msxml или excel, если файл, который тебе генерит какая-нть левая прога или ежеутренне скидывает клиент, содержит что-то слегка не то?
Имхо, задача подкрутки на 4.56 порядка проще написания парсера, особенно для неизвестного тебе формата.

J>>А зачем им писать код, когда можно не писать?

G>Потому что многие вещи можно делать и без regexp, причем более очевидными способами. Типа замены запятых на точки.
Регэкспы как раз хороши тем, что предоставляют универсальный интерфейс к таким задачам. В отличие от "более очевидных способов", ради которых придется менять код, потому что нужен уже не один метод замены, а другой, или вообще оба.

J>>Т.е. ты по логам шаришься ПЕГом?

G>Я по логам обычно шарюсь готовыми утилитами или текстовым поиском.
Замечательно. И в каком виде "готовые утилиты" и "текстовый поиск" предоставляют ввод паттерна для поиска? У меня вот сплошь регэкспы, ПЕГа не видно что-то.

J>>Регэкспу пофиг на грамматику текста. А ПЕГ как раз ее и описывает, для этого ты ее должен, по крайней мере, понимать.

G>Regexp тоже описывает грамматику, причем вполне определенного вида.
Можешь раскрыть мысль? На мой взгляд, грамматика подразумевает дерево, описывающее структуру текста. В регэкспах никакого дерева нет.
Например, последовательность аминокислот в ДНК — какая тут может быть грамматикаами? А между тем регэкспы там рулят.
Регэкспы начинают сливать, когда тебе нужна именно грамматика, например, есть рекурсивные вещи. Вот в таких случаях ПЕГ будет рулить.

G>>>Кроме того с PEG можно комбинировать парсеры между собой.

J>>так же, как и регэкспы.
G>Покажи.
G>Особо инересен случай когда клеите regex такого вида: (re1 И НЕ re2)
(?!re2)re1

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

G>>>Так тебе в любом случае нужен парсер выражений. Ты кого обмануть пытаешься?
J>>Не нужен, он уже есть. А мне всего лишь нужно слегка подкрутить текст, который я ему отдаю на вход.
G>И что? Ты и в дельнейшем будешь всегда ориентировать на то что парсер уже есть, а тебе надо "лишь нужно слегка подкрутить текст"?
Естественно (см. выше). Если парсер есть, конечно. Мы тут начали с обсуждения проблемы Мамута, у которого парсер уже есть, и надо подкрутить текст.
Если парсера нет и он нужен — я построю полноценный парсер в том или ином виде (PEG/EBNF/whatever).
А он нужен либо когда мне нужно не просто преобразовать текст, а извлечь из него какую-то информацию, и при этом "обычный" регэксп будет работать неправильно из-за сложной грамматики текста (рекурсии типа вложенных парных скобок и т.п.) (ЗЫ "Не обычные" регэкспы в перле позволяют и вложенные парные скобки матчить). Потому что для простых текстов информация элементарно извлекается и регэкспами, и обычно это более удобно за счет откатываемых кванторов и настройки их жадности.

G>>>>>А regexp не надо писать и отлаживать?

J>>>>В 99% — нет (у меня, по крайней мере). Для оставшегося надо честный парсер писать.
J>>>>Плюс я регэксп всегда могу на перле потестить, это минутное дело. А потом скормить Boost.Regex и прочим (JavaScript, C#) как есть — они все совместимы с перловыми регэкспами.
G>У haskell есть repl, которым ты очень быстро можешь протестить парсер
ну хорошо. Этот парсер на других яэыках заработает потом или он все-таки haskell-only?

J>>как у нас в ПЕГе насчет обратных ссылок и прочего?

G>Да там вообще такого говна нет, у него есть более полезные примитивы,
Что ты там говорил намедни насчет эмоциональных оценок? Если в ПЕГе нет, значит, г и не нужно?
И какие примитивы, которых нет в регэкспах, имеются в виду?

G>а еще в правильном парсере есть вывод правила, в котором мы можем сказать fail для любого неустраиваюего нас выражения.

что ты понимаешь под "выводом правила"?
И что такое "правильный парсер"? Я так понимаю, это что-то за пределами ПЕГа?
Ну и напиши мне ПЕГ для std::vector заодно, я пример давал уже несколько раз.

J>>>>Это все понятно, я не о сферической нотации в вакууме, а о тех регэкспах, о которых ты говорил, которые у тебя в твоей программе. Насколько критично их ускорять? Только честно.

G>>>хз, я вообще не парился по поводу производительности регэкспов, мне даже мерить лень.
J>>Ну а к чему тогда все эти разговоры про то, что можно было бы твои регэкспы переписать на ПЕГ и компилировать в статике? Именно те регэкспы, которые у тебя в твоей программе?
G>К тому что компиляция PEG (или любого другого парсера) в compile-time дает больше простора для оптимизиции, тупо по времени. Если будет в рантайме компилироваться в течение 20 секунд, то все пошлют нах такой инструмент.
Ты сам себе противоречишь. Только что ты сказал, что производительность регэкспов в твоем production-коде тебя не волнует. Простота нынешнего решения с регэкспами, я думаю, тебя тоже устраивает. Так и к чему этот разговор?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[43]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 27.01.11 10:01
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>Я вот как-то в админе в основном копи-пейстом запросы составляю, и ничего. Та же склейка строк

G>Данивопрос. Вот у тебя есть запрос в виде текста, возможно как-то побитый на части. внезапно тебе понадобилось добавить туда еще один джоин и условия фильтрации на поля этой таблицы. Попробуй написать такой код, который позволяет произвольно выполнять такие действия и при этом гарантировать корректность получившегося SQL.

Ты лучше пример приведи.
Потому что с условиями фильтрации у меня проблем никогда не было: "WHERE 1=1 " и дальше условия через AND в произвольном порядке.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[44]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.01.11 10:39
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>>>Не говоря уж о тех, кому страшно не повезло со всякими MSXML и т.п., которые, вот незадача, принимают текст на вход.

G>>И что? Это значит что и в дальнейшем надо ориентироваться на то что кто-то уже написал парсер и придумывать к нему костыли?
J>Естественно.
Бред, мы же говорим о нестандартных форматах, вводимых пользователем.
Если бы все делалось исключительно xml-парсерами, то вообще не было бы необходимости даже в regex.

J>Имхо, задача подкрутки на 4.56 порядка проще написания парсера, особенно для неизвестного тебе формата.

Вот я и говорю что ты свято вершишь что написание даже простого парсера — нереально сложная задача. А на деле — совсем несложная при наличии нормальных инструментов.

J>>>А зачем им писать код, когда можно не писать?

G>>Потому что многие вещи можно делать и без regexp, причем более очевидными способами. Типа замены запятых на точки.
J>Регэкспы как раз хороши тем, что предоставляют универсальный интерфейс к таким задачам.
Я тебе даже больше скажу, все можно свести к задаче распознавания строки (подстроки), только для большинства ест и более простые и эффективные способы.

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

А чем "менять regex" лучше чем "менять код"?

J>>>Т.е. ты по логам шаришься ПЕГом?

G>>Я по логам обычно шарюсь готовыми утилитами или текстовым поиском.
J>Замечательно. И в каком виде "готовые утилиты" и "текстовый поиск" предоставляют ввод паттерна для поиска? У меня вот сплошь регэкспы, ПЕГа не видно что-то.
А у меня ровно наоборот. Наверное потому что ты парсишь логи в консоли с помощью grep, а я в винде работаю с окошками и тупо кликаю в таблице "показать все с этим значением".

J>>>Регэкспу пофиг на грамматику текста. А ПЕГ как раз ее и описывает, для этого ты ее должен, по крайней мере, понимать.

G>>Regexp тоже описывает грамматику, причем вполне определенного вида.
J>Можешь раскрыть мысль? На мой взгляд, грамматика подразумевает дерево, описывающее структуру текста.
Формальная грамматика


J>В регэкспах никакого дерева нет.

Это их недостаток.

J>Например, последовательность аминокислот в ДНК — какая тут может быть грамматикаами? А между тем регэкспы там рулят.

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

G>>>>Кроме того с PEG можно комбинировать парсеры между собой.

J>>>так же, как и регэкспы.
G>>Покажи.
G>>Особо инересен случай когда клеите regex такого вида: (re1 И НЕ re2)
J>(?!re2)re1
не смог запустить ни в одном из имеющихся средств.

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

G>>>>Так тебе в любом случае нужен парсер выражений. Ты кого обмануть пытаешься?
J>>>Не нужен, он уже есть. А мне всего лишь нужно слегка подкрутить текст, который я ему отдаю на вход.
G>>И что? Ты и в дельнейшем будешь всегда ориентировать на то что парсер уже есть, а тебе надо "лишь нужно слегка подкрутить текст"?
J>Естественно (см. выше). Если парсер есть, конечно. Мы тут начали с обсуждения проблемы Мамута, у которого парсер уже есть, и надо подкрутить текст.
Так проблема в том что "парсер уже есть", а причем тут преимущества regex — непонятно.

J>Если парсера нет и он нужен — я построю полноценный парсер в том или ином виде (PEG/EBNF/whatever).

Еще раз. Ты зря считаешь слишком сложным разработку простых парсеров. С правильными инструментами это на ура делается.

G>>>>>>А regexp не надо писать и отлаживать?

J>>>>>В 99% — нет (у меня, по крайней мере). Для оставшегося надо честный парсер писать.
J>>>>>Плюс я регэксп всегда могу на перле потестить, это минутное дело. А потом скормить Boost.Regex и прочим (JavaScript, C#) как есть — они все совместимы с перловыми регэкспами.
G>>У haskell есть repl, которым ты очень быстро можешь протестить парсер
J>ну хорошо. Этот парсер на других яэыках заработает потом или он все-таки haskell-only?
Да, скомилишь в С, потом как либу к любому другому языку подключай.


J>>>как у нас в ПЕГе насчет обратных ссылок и прочего?

G>>Да там вообще такого говна нет, у него есть более полезные примитивы,
J>Что ты там говорил намедни насчет эмоциональных оценок? Если в ПЕГе нет, значит, г и не нужно?
J>И какие примитивы, которых нет в регэкспах, имеются в виду?
Рекурсия.

G>>а еще в правильном парсере есть вывод правила, в котором мы можем сказать fail для любого неустраиваюего нас выражения.

J>что ты понимаешь под "выводом правила"?
J>И что такое "правильный парсер"? Я так понимаю, это что-то за пределами ПЕГа?
J>Ну и напиши мне ПЕГ для std::vector заодно, я пример давал уже несколько раз.
А ты напиши в regex разбор арифметических выражений с приоритетами
Мне просто некайф заниматься писанием.

J>>>>>Это все понятно, я не о сферической нотации в вакууме, а о тех регэкспах, о которых ты говорил, которые у тебя в твоей программе. Насколько критично их ускорять? Только честно.

G>>>>хз, я вообще не парился по поводу производительности регэкспов, мне даже мерить лень.
J>>>Ну а к чему тогда все эти разговоры про то, что можно было бы твои регэкспы переписать на ПЕГ и компилировать в статике? Именно те регэкспы, которые у тебя в твоей программе?
G>>К тому что компиляция PEG (или любого другого парсера) в compile-time дает больше простора для оптимизиции, тупо по времени. Если будет в рантайме компилироваться в течение 20 секунд, то все пошлют нах такой инструмент.
J>Ты сам себе противоречишь. Только что ты сказал, что производительность регэкспов в твоем production-коде тебя не волнует. Простота нынешнего решения с регэкспами, я думаю, тебя тоже устраивает. Так и к чему этот разговор?
Так это ты начал. Я же говорю что большинство regex статичны на момент компиляции и никто не мешает компилировать их в код со всеми возмодными проверками и оптимизациями.
Меряться ты захотел, хотя я не пойму зачем.
Re[44]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.01.11 10:44
Оценка: +1
Здравствуйте, jazzer, Вы писали:

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


J>>>Я вот как-то в админе в основном копи-пейстом запросы составляю, и ничего. Та же склейка строк

G>>Данивопрос. Вот у тебя есть запрос в виде текста, возможно как-то побитый на части. внезапно тебе понадобилось добавить туда еще один джоин и условия фильтрации на поля этой таблицы. Попробуй написать такой код, который позволяет произвольно выполнять такие действия и при этом гарантировать корректность получившегося SQL.

J>Ты лучше пример приведи.

J>Потому что с условиями фильтрации у меня проблем никогда не было: "WHERE 1=1 " и дальше условия через AND в произвольном порядке.

Был запрос

select x,y,z,from a
where x=xx


надо простым способом из него получить запрос

select x,y,z,from a
left join b on a.key = b.key
where x=xx and b.y = yy
Re[45]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 28.01.11 03:09
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>Ты лучше пример приведи.

J>>Потому что с условиями фильтрации у меня проблем никогда не было: "WHERE 1=1 " и дальше условия через AND в произвольном порядке.

G>Был запрос


G>select x,y,z,from a
G>where x=xx


G>надо простым способом из него получить запрос


G>select x,y,z,from a
G>left join b on a.key = b.key
G>where x=xx and b.y = yy

А что здесь сложного? Я вставки выделил, копи-пейстом они делаются без проблем. Проблем в этом конркетном запросе не видно.
Люди же практически конкатенацией и занимаются, когда редактируют запросы на лету, включая/выключая фрагменты при помощи комментариев:
select x,y,z,from a
--left join b on a.key = b.key
where x=xx
--and b.y = yy


Но, согласись, SQL намного сложнее регэкспа, потому что регэкспы локальны (т.е. вставка будет ровно в одно место), а в SQL даже для того, чтоб добавить пару столбцов из другой таблицы, тебе придётся делать вставки в несколько разных мест: список столбцов, список таблиц, список условий, список условий группировки... Так что сравнивать конкатенацию регэкспов и SQL особого смысла не имеет.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[45]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 28.01.11 05:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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


J>>>>Не говоря уж о тех, кому страшно не повезло со всякими MSXML и т.п., которые, вот незадача, принимают текст на вход.

G>>>И что? Это значит что и в дальнейшем надо ориентироваться на то что кто-то уже написал парсер и придумывать к нему костыли?
J>>Естественно.
G>Бред, мы же говорим о нестандартных форматах, вводимых пользователем.
Нет, мы говорим о подкрутке исходного файла для приведения его к стандартному формату.
И не только.
G>Если бы все делалось исключительно xml-парсерами, то вообще не было бы необходимости даже в regex.
а по делу? сколько можно "отвечать" на одно наугад выбранное слово?

J>>Имхо, задача подкрутки на 4.56 порядка проще написания парсера, особенно для неизвестного тебе формата.

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

J>>>>А зачем им писать код, когда можно не писать?

G>>>Потому что многие вещи можно делать и без regexp, причем более очевидными способами. Типа замены запятых на точки.
J>>Регэкспы как раз хороши тем, что предоставляют универсальный интерфейс к таким задачам.
G>Я тебе даже больше скажу, все можно свести к задаче распознавания строки (подстроки), только для большинства ест и более простые и эффективные способы.
у нас явно "большинство" различается.
PS И этот человек спрашивал, где я траву беру

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

G>А чем "менять regex" лучше чем "менять код"?
тем, что регэксп в конфиге лежит, его там можно вообще поменять.
Например, AdBlock в FireFox ищет рекламу по регэкспам. Которые задаются юзером. По-твоему, правильнее было бы, если бы юзеры лезли непосредственно в код ад-блока и крутили парсер прямо там?


J>>>>Т.е. ты по логам шаришься ПЕГом?

G>>>Я по логам обычно шарюсь готовыми утилитами или текстовым поиском.
J>>Замечательно. И в каком виде "готовые утилиты" и "текстовый поиск" предоставляют ввод паттерна для поиска? У меня вот сплошь регэкспы, ПЕГа не видно что-то.
G>А у меня ровно наоборот. Наверное потому что ты парсишь логи в консоли с помощью grep, а я в винде работаю с окошками и тупо кликаю в таблице "показать все с этим значением".
И в каком месте ты в винде вводишь ПЕГ? В окошке Search/Replace?

J>>>>Регэкспу пофиг на грамматику текста. А ПЕГ как раз ее и описывает, для этого ты ее должен, по крайней мере, понимать.

G>>>Regexp тоже описывает грамматику, причем вполне определенного вида.
J>>Можешь раскрыть мысль? На мой взгляд, грамматика подразумевает дерево, описывающее структуру текста.
G>Формальная грамматика
это называется "раскрыть мысль"?

J>>В регэкспах никакого дерева нет.

G>Это их недостаток.
зависит от задачи. Если мне нужно просто заменить в файле www.rsdn.ru на rsdn.ru — зачем мне дерево? Зачем мне грамматика? Регэкспы для таких вот задач нужны, а не для вывернутого парсинга.

J>>Например, последовательность аминокислот в ДНК — какая тут может быть грамматикаами? А между тем регэкспы там рулят.

J>>Регэкспы начинают сливать, когда тебе нужна именно грамматика, например, есть рекурсивные вещи. Вот в таких случаях ПЕГ будет рулить.
G>Ты сильно не понимаешь что означает грамматика.
грамматика вообще многозначное слово.

G>>>>>Кроме того с PEG можно комбинировать парсеры между собой.

J>>>>так же, как и регэкспы.
G>>>Покажи.
G>>>Особо инересен случай когда клеите regex такого вида: (re1 И НЕ re2)
J>>(?!re2)re1
G>не смог запустить ни в одном из имеющихся средств.
а в каких ты пробовал?

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

G>>>>>Так тебе в любом случае нужен парсер выражений. Ты кого обмануть пытаешься?
J>>>>Не нужен, он уже есть. А мне всего лишь нужно слегка подкрутить текст, который я ему отдаю на вход.
G>>>И что? Ты и в дельнейшем будешь всегда ориентировать на то что парсер уже есть, а тебе надо "лишь нужно слегка подкрутить текст"?
J>>Естественно (см. выше). Если парсер есть, конечно. Мы тут начали с обсуждения проблемы Мамута, у которого парсер уже есть, и надо подкрутить текст.
G>Так проблема в том что "парсер уже есть", а причем тут преимущества regex — непонятно.
Нет, проблема в том, что есть парсер, и есть текст, который не вполне ему соответствует. И задача в том, чтоб подружить их. Я предлагаю подкрутить текст, и тут рулят регэкспы, ты предлагаешь подкрутить/переписать парсер.

J>>Если парсера нет и он нужен — я построю полноценный парсер в том или ином виде (PEG/EBNF/whatever).

G>Еще раз. Ты зря считаешь слишком сложным разработку простых парсеров.
не считаю, я их на спирите сотню написал. Хватит уже повторять это как заклинание. Я считаю разработку парсера более трудной задачей, чем разработку регэкспа. В области применения регэкспов, естественно, а не в парсинге С++.
G>С правильными инструментами это на ура делается.
Правильные инструменты — это хаскель?

G>>>>>>>А regexp не надо писать и отлаживать?

J>>>>>>В 99% — нет (у меня, по крайней мере). Для оставшегося надо честный парсер писать.
J>>>>>>Плюс я регэксп всегда могу на перле потестить, это минутное дело. А потом скормить Boost.Regex и прочим (JavaScript, C#) как есть — они все совместимы с перловыми регэкспами.
G>>>У haskell есть repl, которым ты очень быстро можешь протестить парсер
J>>ну хорошо. Этот парсер на других яэыках заработает потом или он все-таки haskell-only?
G>Да, скомилишь в С, потом как либу к любому другому языку подключай.
А, гут. Как насчет Javascript и иже с ними?

J>>>>как у нас в ПЕГе насчет обратных ссылок и прочего?

G>>>Да там вообще такого говна нет, у него есть более полезные примитивы,
J>>Что ты там говорил намедни насчет эмоциональных оценок? Если в ПЕГе нет, значит, г и не нужно?
J>>И какие примитивы, которых нет в регэкспах, имеются в виду?
G>Рекурсия.
Про рекурсию я и сам писал уже, тут мы вроде не спорим. Я недостатки регэкспов не скрывал никогда. А вот ты про отсутствующие фичи ПЕГ предпочитаешь умалчивать.

G>А ты напиши в regex разбор арифметических выражений с приоритетами

Не буду, это не задача для регэкспа. Это ж вы, фанатики ПЕГа, кричите, что регэкспы не нужны, ПЕГ всё заменит. А я говорю, что каждому своя область применения. Разбор выражений — это задача для ПЕГа.
J>>Ну и напиши мне ПЕГ для std::vector заодно, я пример давал уже несколько раз.
G>Мне просто некайф заниматься писанием.
Слив засчитан. Но ты не расстраивайся, не ты первый.

J>>>>>>Это все понятно, я не о сферической нотации в вакууме, а о тех регэкспах, о которых ты говорил, которые у тебя в твоей программе. Насколько критично их ускорять? Только честно.

G>>>>>хз, я вообще не парился по поводу производительности регэкспов, мне даже мерить лень.
J>>>>Ну а к чему тогда все эти разговоры про то, что можно было бы твои регэкспы переписать на ПЕГ и компилировать в статике? Именно те регэкспы, которые у тебя в твоей программе?
G>>>К тому что компиляция PEG (или любого другого парсера) в compile-time дает больше простора для оптимизиции, тупо по времени. Если будет в рантайме компилироваться в течение 20 секунд, то все пошлют нах такой инструмент.
J>>Ты сам себе противоречишь. Только что ты сказал, что производительность регэкспов в твоем production-коде тебя не волнует. Простота нынешнего решения с регэкспами, я думаю, тебя тоже устраивает. Так и к чему этот разговор?
G>Так это ты начал. Я же говорю что большинство regex статичны на момент компиляции и никто не мешает компилировать их в код со всеми возмодными проверками и оптимизациями.
G>Меряться ты захотел, хотя я не пойму зачем.
Затем, что непонятен выигрыш от этого.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[45]: Надоело
От: jazzer Россия Skype: enerjazzer
Дата: 28.01.11 05:37
Оценка: 20 (1)
Здравствуйте, gandjustas, Вы писали:

G>>>>>Кроме того с PEG можно комбинировать парсеры между собой.

J>>>>так же, как и регэкспы.
G>>>Покажи.
G>>>Особо инересен случай когда клеите regex такого вида: (re1 И НЕ re2)
J>>(?!re2)re1
G>не смог запустить ни в одном из имеющихся средств.

re1=a. (a + любой символ), re2=aa
> echo "aaab" | perl -ne 'print "$1\n" if m/(a.)/'
aa
> echo "aaab" | perl -ne 'print "$1\n" if m/((?!aa)a.)/'
ab

JavaScript можешь потестировать сам: http://www.regular-expressions.info/javascriptexample.html
Но я почему-то сомневаюсь, что ты это сделаешь, и что ты вообще пробовал что-либо запускать на "своих имеющихся средствах", по опыту дискуссии с тобой, озвученному ниже.

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

J>Далее, никто не мешает собирать регэкспы из простых регэкспов, ибо это просто строчки.
Да ну? У меня есть regex, выделяющий последовательность символов, как мне сделать regex где эта последовательность не встречается в определенном месте?

http://www.rsdn.ru/forum/philosophy/3862887.1.aspx
Автор: gandjustas
Дата: 01.07.10


Далее я показал тебе этот же синтаксис, ты не поверил, спросил, где он поддерживается, кроме перла, я накидал тебе ссылок

J>>На всякий случай: "(?!<regex>)"
G>Такое кажись только perl и поддерживает, но там regex по мощности сравнимы с PEG, но имеют гораздо более хреновый синтаксис.
Да ну?
JavaScript тебя устроит? http://ru.wikipedia.org/wiki/ECMAScript#cite_note-specRegExp-64
Python? http://docs.python.org/library/re.html
С++? http://www.boost.org/libs/regex/doc/html/boost_regex/syntax/perl_syntax.html

http://www.rsdn.ru/forum/philosophy/3863020.1.aspx
Автор: jazzer
Дата: 01.07.10


G>.NET не поддерживает, в java тоже не перловые regex.
Let me Google this for you:
Java: http://java.sun.com/javase/7/docs/api/java/util/regex/Pattern.html Ищи заголовок "Special constructs (named-capturing and non-capturing)"
.NET: http://msdn.microsoft.com/en-us/library/az24scfc.aspx#grouping_constructs

http://www.rsdn.ru/forum/philosophy/3863802.1.aspx
Автор: jazzer
Дата: 02.07.10


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

G>>И как будет выглядеть исключение некоторой подстроки в выражении?
J>Я правильно понял, что ты ссылку и не подумал открыть даже?

    (?!...)
    Matches if ... doesn’t match next. This is a negative lookahead assertion.
    For example, Isaac (?!Asimov) will match 'Isaac ' only if it’s not followed by 'Asimov'.

Я открыл, но ботать здоровые спецификации мне лениво.

http://www.rsdn.ru/forum/philosophy/3863682.1.aspx
Автор: gandjustas
Дата: 01.07.10


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

Извини, но у меня нет ни времени, ни желания продолжать дискуссию в таком режиме. Имей хоть каплю уважения к своему оппоненту.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[46]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.01.11 06:44
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>>>Ты лучше пример приведи.

J>>>Потому что с условиями фильтрации у меня проблем никогда не было: "WHERE 1=1 " и дальше условия через AND в произвольном порядке.

G>>Был запрос


J>
G>>select x,y,z,from a
G>>where x=xx
J>


G>>надо простым способом из него получить запрос


J>
G>>select x,y,z,from a
G>>left join b on a.key = b.key
G>>where x=xx and b.y = yy
J>

J>А что здесь сложного? Я вставки выделил, копи-пейстом они делаются без проблем. Проблем в этом конркетном запросе не видно.
Я привел самый простой случай. В запроса уже может быть join на эту же таблицу. Еще интереснее join на подзапрос, приходится придумывать механизм, который в подзапросы проталкивет проекцию.

J>Люди же практически конкатенацией и занимаются, когда редактируют запросы на лету, включая/выключая фрагменты при помощи комментариев

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

Ты ведь арифметические выражения можешь посчитать если посмотришь на него, а писать парсер — дело относительно сложное.

J>Но, согласись, SQL намного сложнее регэкспа, потому что регэкспы локальны (т.е. вставка будет ровно в одно место), а в SQL даже для того, чтоб добавить пару столбцов из другой таблицы, тебе придётся делать вставки в несколько разных мест: список столбцов, список таблиц, список условий, список условий группировки... Так что сравнивать конкатенацию регэкспов и SQL особого смысла не имеет.

Так вот в этом и прикол, пока regexp "локальны" (хотя ты сказал что грамматика регулярна) то написать и использовать regexp легко, но и на peg можно написать также легко для регулярной грамматики. А вот когда грамматика становится нерегулярной, то regexp_ы начинают сливать, становятся слишком сложными.
Re[46]: PEG vs RegExp
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.01.11 06:58
Оценка:
Здравствуйте, jazzer, Вы писали:

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


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


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


J>>>>>Не говоря уж о тех, кому страшно не повезло со всякими MSXML и т.п., которые, вот незадача, принимают текст на вход.

G>>>>И что? Это значит что и в дальнейшем надо ориентироваться на то что кто-то уже написал парсер и придумывать к нему костыли?
J>>>Естественно.
G>>Бред, мы же говорим о нестандартных форматах, вводимых пользователем.
J>Нет, мы говорим о подкрутке исходного файла для приведения его к стандартному формату.
А откуда он в нестандартном формате возмется?

J>>>Имхо, задача подкрутки на 4.56 порядка проще написания парсера, особенно для неизвестного тебе формата.

G>>Вот я и говорю что ты свято вершишь что написание даже простого парсера — нереально сложная задача. А на деле — совсем несложная при наличии нормальных инструментов.
J>одно с другим никак не связано вообще.
Это тебе так кажется.

J>>>>>А зачем им писать код, когда можно не писать?

G>>>>Потому что многие вещи можно делать и без regexp, причем более очевидными способами. Типа замены запятых на точки.
J>>>Регэкспы как раз хороши тем, что предоставляют универсальный интерфейс к таким задачам.
G>>Я тебе даже больше скажу, все можно свести к задаче распознавания строки (подстроки), только для большинства ест и более простые и эффективные способы.
J>у нас явно "большинство" различается.
Именно, потому что у тебя взгляд замылен используемыми инструментами.

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

G>>А чем "менять regex" лучше чем "менять код"?
J>тем, что регэксп в конфиге лежит, его там можно вообще поменять.
J>Например, AdBlock в FireFox ищет рекламу по регэкспам. Которые задаются юзером. По-твоему, правильнее было бы, если бы юзеры лезли непосредственно в код ад-блока и крутили парсер прямо там?
Это ты рассматриваешь случай задания правил пользователем.
Кроме того тебе повезло, грамматика url — регулярна.


J>>>>>Т.е. ты по логам шаришься ПЕГом?

G>>>>Я по логам обычно шарюсь готовыми утилитами или текстовым поиском.
J>>>Замечательно. И в каком виде "готовые утилиты" и "текстовый поиск" предоставляют ввод паттерна для поиска? У меня вот сплошь регэкспы, ПЕГа не видно что-то.
G>>А у меня ровно наоборот. Наверное потому что ты парсишь логи в консоли с помощью grep, а я в винде работаю с окошками и тупо кликаю в таблице "показать все с этим значением".
J>И в каком месте ты в винде вводишь ПЕГ? В окошке Search/Replace?
Еще раз: я там вообще не занимаюсь парсингом ни в каком виде.

J>>>>>Регэкспу пофиг на грамматику текста. А ПЕГ как раз ее и описывает, для этого ты ее должен, по крайней мере, понимать.

G>>>>Regexp тоже описывает грамматику, причем вполне определенного вида.
J>>>Можешь раскрыть мысль? На мой взгляд, грамматика подразумевает дерево, описывающее структуру текста.
G>>Формальная грамматика
J>это называется "раскрыть мысль"?
Это чтобы ты понял что такое грамматика.

J>>>В регэкспах никакого дерева нет.

G>>Это их недостаток.
J>зависит от задачи. Если мне нужно просто заменить в файле www.rsdn.ru на rsdn.ru — зачем мне дерево? Зачем мне грамматика? Регэкспы для таких вот задач нужны, а не для вывернутого парсинга.
.replace("www.",""), зачем тебе regexp?

J>>>Например, последовательность аминокислот в ДНК — какая тут может быть грамматикаами? А между тем регэкспы там рулят.

J>>>Регэкспы начинают сливать, когда тебе нужна именно грамматика, например, есть рекурсивные вещи. Вот в таких случаях ПЕГ будет рулить.
G>>Ты сильно не понимаешь что означает грамматика.
J>грамматика вообще многозначное слово.
Нет, смотри определение.

G>>>>>>Кроме того с PEG можно комбинировать парсеры между собой.

J>>>>>так же, как и регэкспы.
G>>>>Покажи.
G>>>>Особо инересен случай когда клеите regex такого вида: (re1 И НЕ re2)
J>>>(?!re2)re1
G>>не смог запустить ни в одном из имеющихся средств.
J>а в каких ты пробовал?
VS 2010, GHC

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

G>>>>>>Так тебе в любом случае нужен парсер выражений. Ты кого обмануть пытаешься?
J>>>>>Не нужен, он уже есть. А мне всего лишь нужно слегка подкрутить текст, который я ему отдаю на вход.
G>>>>И что? Ты и в дельнейшем будешь всегда ориентировать на то что парсер уже есть, а тебе надо "лишь нужно слегка подкрутить текст"?
J>>>Естественно (см. выше). Если парсер есть, конечно. Мы тут начали с обсуждения проблемы Мамута, у которого парсер уже есть, и надо подкрутить текст.
G>>Так проблема в том что "парсер уже есть", а причем тут преимущества regex — непонятно.
J>Нет, проблема в том, что есть парсер, и есть текст, который не вполне ему соответствует. И задача в том, чтоб подружить их. Я предлагаю подкрутить текст, и тут рулят регэкспы, ты предлагаешь подкрутить/переписать парсер.
Не своди задачу к удобной тебе. Рассмотри более общую задачу.
Можно вообще любой говнокод оправдать тем что "у нас уже есть готовый функционал и надо к нему костыль написать".

J>>>Если парсера нет и он нужен — я построю полноценный парсер в том или ином виде (PEG/EBNF/whatever).

G>>Еще раз. Ты зря считаешь слишком сложным разработку простых парсеров.
J>не считаю, я их на спирите сотню написал. Хватит уже повторять это как заклинание. Я считаю разработку парсера более трудной задачей, чем разработку регэкспа. В области применения регэкспов, естественно, а не в парсинге С++.
Ну вот и я об этом.

G>>С правильными инструментами это на ура делается.

J>Правильные инструменты — это хаскель?
Нет, правильные инструменты позволяют уменьшить затраты на разработку парсеров.

G>>>>>>>>А regexp не надо писать и отлаживать?

J>>>>>>>В 99% — нет (у меня, по крайней мере). Для оставшегося надо честный парсер писать.
J>>>>>>>Плюс я регэксп всегда могу на перле потестить, это минутное дело. А потом скормить Boost.Regex и прочим (JavaScript, C#) как есть — они все совместимы с перловыми регэкспами.
G>>>>У haskell есть repl, которым ты очень быстро можешь протестить парсер
J>>>ну хорошо. Этот парсер на других яэыках заработает потом или он все-таки haskell-only?
G>>Да, скомилишь в С, потом как либу к любому другому языку подключай.
J>А, гут. Как насчет Javascript и иже с ними?
ActiveX

J>>>>>как у нас в ПЕГе насчет обратных ссылок и прочего?

G>>>>Да там вообще такого говна нет, у него есть более полезные примитивы,
J>>>Что ты там говорил намедни насчет эмоциональных оценок? Если в ПЕГе нет, значит, г и не нужно?
J>>>И какие примитивы, которых нет в регэкспах, имеются в виду?
G>>Рекурсия.
J>Про рекурсию я и сам писал уже, тут мы вроде не спорим. Я недостатки регэкспов не скрывал никогда. А вот ты про отсутствующие фичи ПЕГ предпочитаешь умалчивать.
Просто не пойму зачем мне тебе доказывать что peg-парсеры могут парсить все КС-грамматики. Это факт.

G>>А ты напиши в regex разбор арифметических выражений с приоритетами

J>Не буду, это не задача для регэкспа. Это ж вы, фанатики ПЕГа, кричите, что регэкспы не нужны, ПЕГ всё заменит. А я говорю, что каждому своя область применения. Разбор выражений — это задача для ПЕГа.
J>>>Ну и напиши мне ПЕГ для std::vector заодно, я пример давал уже несколько раз.
G>>Мне просто некайф заниматься писанием.
J>Слив засчитан. Но ты не расстраивайся, не ты первый.
Конечно, всем некайф.
Твоя работа — сам делай.

G>>Так это ты начал. Я же говорю что большинство regex статичны на момент компиляции и никто не мешает компилировать их в код со всеми возмодными проверками и оптимизациями.

G>>Меряться ты захотел, хотя я не пойму зачем.
J>Затем, что непонятен выигрыш от этого.
См выделенное.
Re[46]: Надоело
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.01.11 07:02
Оценка:
Здравствуйте, jazzer, Вы писали:

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

Ну конечно лениво. Ты продолжаешь опираться на то что для тебя разработка парсера гораздо сложнее написания regex. Для меня также было, пока не попробовал пользоваться хорошими инструментами для этого дела. Но ты в это никак не хочешь вникать.
Re[47]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 28.01.11 07:12
Оценка:
Здравствуйте, gandjustas, Вы писали:

J>>Но, согласись, SQL намного сложнее регэкспа, потому что регэкспы локальны (т.е. вставка будет ровно в одно место), а в SQL даже для того, чтоб добавить пару столбцов из другой таблицы, тебе придётся делать вставки в несколько разных мест: список столбцов, список таблиц, список условий, список условий группировки... Так что сравнивать конкатенацию регэкспов и SQL особого смысла не имеет.

G>Так вот в этом и прикол, пока regexp "локальны" (хотя ты сказал что грамматика регулярна)...
это где я такое сказал? Или, вернее сказать, какие мои слова ты так интерпретировал?

G>...то написать и использовать regexp легко, но и на peg можно написать также легко для регулярной грамматики. А вот когда грамматика становится нерегулярной, то regexp_ы начинают сливать, становятся слишком сложными.

Ты здесь под грамматикой имеешь в вижу грамматику запроса или грамматику текста, над которым мы изгаляемся?
Я к тому, что у С++ сложная грамматика, но во многих запросах нас эта грамматика не будет интересовать (т.е. когда мы работаем с текстом программы просто как с текстом).
А когда нам понадобится тот факт, что мы имеем дело не просто с текстом, но с кодом С++, тогда нам, скорее всего, и понадобится полноценный парсер (ПЕГ или регэкпы "на стероидах", типа тех, которые умеют парсить вложенные парные скобки).
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[47]: PEG vs RegExp
От: Mamut Швеция http://dmitriid.com
Дата: 28.01.11 07:18
Оценка:
J>>Но, согласись, SQL намного сложнее регэкспа, потому что регэкспы локальны (т.е. вставка будет ровно в одно место), а в SQL даже для того, чтоб добавить пару столбцов из другой таблицы, тебе придётся делать вставки в несколько разных мест: список столбцов, список таблиц, список условий, список условий группировки... Так что сравнивать конкатенацию регэкспов и SQL особого смысла не имеет.
G>Так вот в этом и прикол, пока regexp "локальны" (хотя ты сказал что грамматика регулярна) то написать и использовать regexp легко, но и на peg можно написать также легко для регулярной грамматики.

Ключевая разница выделена.

regexp можно и легко написать и легко использовать. а peg — только написать


Как в моем примере. Парсер же есть. Для того, чтоб привести строку к его вилу PEG будет overkill'ом. А пример решения для задачи jazzer'а вообще никто так и не привел.


dmitriid.comGitHubLinkedIn
Re[47]: Надоело
От: Mamut Швеция http://dmitriid.com
Дата: 28.01.11 07:30
Оценка: 1 (1)
J>>И сейчас опять по новой? Раз лениво смотреть ссылки, раз лениво уделять должное внимание репликам и аргументам оппонента, то не надо имитировать дискуссию ленивыми отписками.
G>Ну конечно лениво. Ты продолжаешь опираться на то что для тебя разработка парсера гораздо сложнее написания regex.

В пятидесятый раз.

Парсер уже есть. Он обрабатывает некий текст определенного формата. Мы получаем на вход данные, которые не совсем соответствуют этому формату.

1. Код парсера недоступен.
2. Код доступен, но для приведения в соответствие с входящим текстам его надо переписывать.

Нахрена в этих двух случаях PEG, если search/replace решается regexp'ом за полторы минуты? При нормальном комментарии к коду это не write-only костыль, а рабочее решение.

Ты же уперся рогом в «напиши парсер напиши парсер напиши парсер напиши парсер напиши парсер напиши парсер напиши парсер напиши парсер», хотя тебе уже писали, например:

Gandjustas>
Странно, почему всегда сводится к тому что "уже есть что-то что никак нельзя менять"?
Если не рассматривать такие, вообще говоря паталогические, случаи найдутся у regexp преимущества?

Jazzer>
Что-то мне подозрительно много патологических случаев попадается. Эксель в их числе, кстати.

Gandjustas>
не повезло.

Jazzer>
С Экселем, боюсь, всем не повезло.
Мамуту вон тоже не повезло — у него библиотека, сволочь такая, УЖЕ умеет парсить.
Не говоря уж о тех, кому страшно не повезло со всякими MSXML и т.п., которые, вот незадача, принимают текст на вход.

Gandjustas>
И что? Это значит что и в дальнейшем надо ориентироваться на то что кто-то уже написал парсер и придумывать к нему костыли?

Jazzer>
Естественно.
А что, кто-то в здравом уме начнет переписывать msxml или excel, если файл, который тебе генерит какая-нть левая прога или ежеутренне скидывает клиент, содержит что-то слегка не то?
Имхо, задача подкрутки на 4.56 порядка проще написания парсера, особенно для неизвестного тебе формата.


И что мы получаем в итоге?

Ты продолжаешь опираться на то что для тебя разработка парсера гораздо сложнее написания regex.


Это ли не [beep]?


dmitriid.comGitHubLinkedIn
Re[48]: Надоело
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.01.11 08:24
Оценка:
Здравствуйте, Mamut, Вы писали:

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

G>>Ну конечно лениво. Ты продолжаешь опираться на то что для тебя разработка парсера гораздо сложнее написания regex.

M>В пятидесятый раз.


M>Парсер уже есть. Он обрабатывает некий текст определенного формата. Мы получаем на вход данные, которые не совсем соответствуют этому формату.


Любой говнокод можно оправдать тем что уже что-то есть чего нельзя трогать и нужен к этому костыль. Поэтому предпочитаю тупо не рассматривать такую ситуацию.
Re[47]: PEG vs RegExp
От: jazzer Россия Skype: enerjazzer
Дата: 28.01.11 09:45
Оценка:
Здравствуйте, gandjustas, Вы писали:
J>>Нет, мы говорим о подкрутке исходного файла для приведения его к стандартному формату.
G>А откуда он в нестандартном формате возмется?
Да откуда угодно. Сгенерила другая программа, или эта же, но с другими настройками (пример — Excel), или человек руками хочет что-то писать покороче (пример Мамута)

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

G>>>А чем "менять regex" лучше чем "менять код"?
J>>тем, что регэксп в конфиге лежит, его там можно вообще поменять.
J>>Например, AdBlock в FireFox ищет рекламу по регэкспам. Которые задаются юзером. По-твоему, правильнее было бы, если бы юзеры лезли непосредственно в код ад-блока и крутили парсер прямо там?
G>Это ты рассматриваешь случай задания правил пользователем.
Да, рассматирваю. Ты что-то с ПЕГом можешь предложить в этой области?

G>Кроме того тебе повезло, грамматика url — регулярна.

Ну, грамматика HTML нерегулярна (есть рекурсия и вложенности), однако плохие линки можно вычистить и там

J>>>>>>Т.е. ты по логам шаришься ПЕГом?

G>>>>>Я по логам обычно шарюсь готовыми утилитами или текстовым поиском.
J>>>>Замечательно. И в каком виде "готовые утилиты" и "текстовый поиск" предоставляют ввод паттерна для поиска? У меня вот сплошь регэкспы, ПЕГа не видно что-то.
G>>>А у меня ровно наоборот. Наверное потому что ты парсишь логи в консоли с помощью grep, а я в винде работаю с окошками и тупо кликаю в таблице "показать все с этим значением".
J>>И в каком месте ты в винде вводишь ПЕГ? В окошке Search/Replace?
G>Еще раз: я там вообще не занимаюсь парсингом ни в каком виде.
Т.е. ты либо парсишь пегом, либо ищешь как есть, без регэкспов? Ну, ССЗБ

J>>зависит от задачи. Если мне нужно просто заменить в файле www.rsdn.ru на rsdn.ru — зачем мне дерево? Зачем мне грамматика? Регэкспы для таких вот задач нужны, а не для вывернутого парсинга.

G>.replace("www.",""), зачем тебе regexp?
затем, что это изменение в коде вместо изменения в конфиге. Т.е. по крайней мере я должен иметь код в своем распоряжении, знать язык, на котором это написано, и уметь пересобирать.

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

G>>>>>Особо инересен случай когда клеите regex такого вида: (re1 И НЕ re2)

J>>>>(?!re2)re1
G>>>не смог запустить ни в одном из имеющихся средств.
J>>а в каких ты пробовал?
G>VS 2010, GHC
Да, молодец, поймал. В студии, несмотря на то, что она написана на дотнете, который поддерживает нормальный перловый синтаксис, решили извратиться и свой синтаксис изобрести, там надо писать так: "~(re2)re1". Придурки, что я могу сказать.

Хаскелл — ну, мы в очередной раз убедились, что ты не знаешь средств разработки, которые используешь.
Let me google this for you:
http://www.haskell.org/haskellwiki/Regular_expressions#regex-pcre

1.5 regex-pcre
This wraps the pcre c-library from http://www.pcre.org and gives all the Perl regular expression syntax you might want. This is especially efficient with Data.ByteString.


G>Не своди задачу к удобной тебе. Рассмотри более общую задачу.

Это ты не своди все задачи к парсингу, на свете много еще чего есть.
G>Можно вообще любой говнокод оправдать тем что "у нас уже есть готовый функционал и надо к нему костыль написать".
Можно, кто ж спорит. Вообще все что угодно можно оправдать всем чем угодно.

J>>не считаю, я их на спирите сотню написал. Хватит уже повторять это как заклинание. Я считаю разработку парсера более трудной задачей, чем разработку регэкспа. В области применения регэкспов, естественно, а не в парсинге С++.

G>Ну вот и я об этом.
А чего ты споришь тогда? Я это в самом первом своем сообщении сказал.

G>>>С правильными инструментами это на ура делается.

J>>Правильные инструменты — это хаскель?
G>Нет, правильные инструменты позволяют уменьшить затраты на разработку парсеров.
конретики хотца.

G>>>Рекурсия.

J>>Про рекурсию я и сам писал уже, тут мы вроде не спорим. Я недостатки регэкспов не скрывал никогда. А вот ты про отсутствующие фичи ПЕГ предпочитаешь умалчивать.
G>Просто не пойму зачем мне тебе доказывать что peg-парсеры могут парсить все КС-грамматики. Это факт.
Ну так ты сам о КС-грамматиках вдруг начал говорить, я-то о них не говорю, и вряд ли они кого-то из юзеров регэкспов интересуют
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[49]: Надоело
От: Mamut Швеция http://dmitriid.com
Дата: 28.01.11 15:25
Оценка:
J>>>>И сейчас опять по новой? Раз лениво смотреть ссылки, раз лениво уделять должное внимание репликам и аргументам оппонента, то не надо имитировать дискуссию ленивыми отписками.
G>>>Ну конечно лениво. Ты продолжаешь опираться на то что для тебя разработка парсера гораздо сложнее написания regex.

M>>В пятидесятый раз.


M>>Парсер уже есть. Он обрабатывает некий текст определенного формата. Мы получаем на вход данные, которые не совсем соответствуют этому формату.


G>Любой говнокод можно оправдать тем что уже что-то есть чего нельзя трогать и нужен к этому костыль. Поэтому предпочитаю тупо не рассматривать такую ситуацию.


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


dmitriid.comGitHubLinkedIn
Re[49]: З.Ы.
От: Mamut Швеция http://dmitriid.com
Дата: 28.01.11 15:25
Оценка:
M>>В пятидесятый раз.

M>>Парсер уже есть. Он обрабатывает некий текст определенного формата. Мы получаем на вход данные, которые не совсем соответствуют этому формату.


G>Любой говнокод можно оправдать тем что уже что-то есть чего нельзя трогать и нужен к этому костыль. Поэтому предпочитаю тупо не рассматривать такую ситуацию.


На вопрос jazzer'а про std::vector так никто и не удосужился ответить.


dmitriid.comGitHubLinkedIn
Re[50]: З.Ы.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 28.01.11 20:50
Оценка: 42 (1)
M>На вопрос jazzer'а про std::vector так никто и не удосужился ответить.

там очень простой peg
query := generic-identifier;
generic-identifier := identifier ('<' generic-identifier (',' S* generic-identifier)* '>' )?;
identifier := [a-zA-Z_:]+;
S := ' ';


+ условное выражение для дерева, например, на xpath:
query/generic-identifier[identifier[1].text='std::vector' && generic-identifier[2].identifier.text ='std::allocator' && generic-identifier.text = generic-identifier[2].generic-identifier[1].text]

пример дерева для варианта jazzer-а будет (остальные аналогично):
query(0, 39) std::vector<char, std::allocator<char>>
.generic-identifier(0, 39) std::vector<char, std::allocator<char>>
..identifier(0, 11) std::vector
..generic-identifier(12, 16) char
...identifier(12, 16) char
..S(17, 18)
..generic-identifier(18, 38) std::allocator<char>
...identifier(18, 32) std::allocator
...generic-identifier(33, 37) char
....identifier(33, 37) char


в пег можно добавить и сам vector и allocator
query := generic-identifier;
generic-identifier := vector / (identifier ('<' generic-identifier (',' S* generic-identifier)* '>' )?);
vector := 'std::vector' '<' generic-identifier ',' S* 'std::allocator' '<' generic-identifier '>' '>';
identifier := [a-zA-Z_:]+;
S := ' ';


условное выражение упростится до
query/generic-identifier/vector[generic-identifier[1].text=generic-identifier[2].text]

дерево будет
query(0, 39) std::vector<char, std::allocator<char>>
.generic-identifier(0, 39) std::vector<char, std::allocator<char>>
..vector(0, 39) std::vector<char, std::allocator<char>>
...generic-identifier(12, 16) char
....identifier(12, 16) char
...S(17, 18)
...generic-identifier(33, 37) char
....identifier(33, 37) char
Re[51]: З.Ы.
От: jazzer Россия Skype: enerjazzer
Дата: 29.01.11 03:50
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>в пег можно добавить и сам vector и allocator

DG>
DG>query := generic-identifier;
DG>generic-identifier := vector / (identifier ('<' generic-identifier (',' S* generic-identifier)* '>' )?);
DG>vector := 'std::vector' '<' generic-identifier ',' S* 'std::allocator' '<' generic-identifier '>' '>';
DG>identifier := [a-zA-Z_:]+;
DG>S := ' ';
DG>

О чем я и говорил. Тебе пришлось написать грамматику для элемента и явно прописать, что есть угловые скобки и они могут быть рекурсивно вложенными (причем это же еще не все, представь, что у тебя элемент содержит угловую скобку, например, что-нть вроде function_wapper< &MyClass::operator> >), а условие задачи было — не писать такой грамматики.

В ПЕГе в принципе нет понятия "последовательность любых символов с откатом" (т.е. оно есть, но не имеет смысла, так как такое правило просто съест всю строчку до конца), поэтому мне придется написать грамматику для этой последовательности, чтоб она не съела больше, чем нужно — очевидный оверкилл для большинства случаев, когда тебе нужно что-нть по-быстрому найти.

http://www.rsdn.ru/forum/philosophy/4120603.1.aspx
Автор: jazzer
Дата: 18.01.11


DG>условное выражение упростится до

DG>query/generic-identifier/vector[generic-identifier[1].text=generic-identifier[2].text]

Итого 5 строчек ПЕГа с явным заданием грамматики элемента плюс строчка с условным выражением, причем ни ПЕГ, ни условие простым не назовешь (первый вариант с более общей грамматикой я даже и не рассматриваю в качестве рабочего, потому что соответствующее условное выражение без поллитра не напишешь).
И это против примитивного std::vector<(.+), std::allocator<\1>>



PS условное выражение на XPath — это удобно
Но это за пределами ПЕГа, ты сам понимаешь
И как, кстати, он будет работать — сначала разберет грамматику, а потом ты отфильтруешь дерево с помощью этого условия? В том смысле, что условие не может использоваться для выяснения, сматчилось правило или нет?
Если так, то как ты на ПЕГе напишешь нечто вроде "\b(\w+)\w*?\1\b" — это регэксп, который найдет строчки, которые начинаются и оканчиваются на одно и то же, с выделением максимально возможной совпадающей части (\b — это граница слова, \w — это [a-zA-Z_])?
Потому что условия в регэкспах работают именно для откатов, если условие не выполнилось, и повторной попытки с менее жадным заглатыванием текста.
А ПЕГ парсит все один раз и однозначно, откатиться и попробовать еще раз невозможно, если нет явно прописанного следующего правила. Я правильно понимаю?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[52]: З.Ы.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 29.01.11 08:06
Оценка:
J>И это против примитивного std::vector<(.+), std::allocator<\1>>
J>

это выражение ты где собираешься применять? для поиска std::vector в произвольном C++-файле?
Re[52]: З.Ы.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 29.01.11 08:38
Оценка:
J>И как, кстати, он будет работать — сначала разберет грамматику, а потом ты отфильтруешь дерево с помощью этого условия? В том смысле, что условие не может использоваться для выяснения, сматчилось правило или нет?

если через простой peg-парсер, то — да

если через peg-парсер с extension-ами, тогда доп. условие проверяется в момент разбора и производит откат текущего правила

J>Если так, то как ты на ПЕГе напишешь нечто вроде "\b(\w+)\w*?\1\b" — это регэксп, который найдет строчки, которые начинаются и оканчиваются на одно и то же, с выделением максимально возможной совпадающей части (\b — это граница слова, \w — это [a-zA-Z_])?

J>Потому что условия в регэкспах работают именно для откатов, если условие не выполнилось, и повторной попытки с менее жадным заглатыванием текста.
J>А ПЕГ парсит все один раз и однозначно, откатиться и попробовать еще раз невозможно, если нет явно прописанного следующего правила. Я правильно понимаю?

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

будет такое
query := b {prefix:}(w{0,-1}) w* prefix b;

{prefix:} — объявляет переменную (на текущей уровне дерева)
prefix — ее использует
w{0,-1} — трактуется — что начинать надо с жадного варианта, а потом откатываться по одному символу
Re[53]: З.Ы.
От: jazzer Россия Skype: enerjazzer
Дата: 29.01.11 14:49
Оценка: +2
Здравствуйте, DarkGray, Вы писали:

J>>И как, кстати, он будет работать — сначала разберет грамматику, а потом ты отфильтруешь дерево с помощью этого условия? В том смысле, что условие не может использоваться для выяснения, сматчилось правило или нет?


DG>если через простой peg-парсер, то — да

+1

DG>если через peg-парсер с extension-ами, тогда доп. условие проверяется в момент разбора и производит откат текущего правила

Ага. В принципе, так же, как с каноническими регэкспами
В том смысле, что их функциональности не хватало, налепили кучу расширений, в результате получились перловые регэкспы

J>>А ПЕГ парсит все один раз и однозначно, откатиться и попробовать еще раз невозможно, если нет явно прописанного следующего правила. Я правильно понимаю?


DG>да, из-за рекурсивного отката простое добавление условия в виде extension-а не поможет,

DG>здесь уже нужно учить делать итерационные откаты,
DG>и подстановки переменных (это для ускорение разбора)

DG>будет такое

DG>
DG>query := b {prefix:}(w{0,-1}) w* prefix b;
DG>

DG>{prefix:} — объявляет переменную (на текущей уровне дерева)
DG>prefix — ее использует
DG>w{0,-1} — трактуется — что начинать надо с жадного варианта, а потом откатываться по одному символу

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

Фактически, после всех этих расширений регэкспы и ПЕГ примерно сравниваются по возможностям, просто они идут к нему с разных сторон и базовый функционал у них разный получается, поэтому то, что легко в регэкспе (кванторы с откатами), трудно в ПЕГе, и наоборот (рекурсия).

З.Ы. А этот движок расширенного ПЕГа, который ты делаешь — он будет открытым или это есть и останется вашей внутренней разработкой?
З.З.Ы. Пользуясь случаем, хочу поблагодарить тебя персонально за дискуссию! В отличие от некоторых других несколько неконструктивных коллег, с тобой было исключительно приятно иметь дело
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[54]: З.Ы.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 29.01.11 15:01
Оценка:
J>З.Ы. А этот движок расширенного ПЕГа, который ты делаешь — он будет открытым или это есть и останется вашей внутренней разработкой?

пока внутренний, дальше будем посмотреть..

J>З.З.Ы. Пользуясь случаем, хочу поблагодарить тебя персонально за дискуссию! В отличие от некоторых других несколько неконструктивных коллег, с тобой было исключительно приятно иметь дело


спасибо.

зы
ты кстати на предыдущий вопрос ответь, про применение regex-а из примера
Re[53]: З.Ы.
От: jazzer Россия Skype: enerjazzer
Дата: 31.01.11 02:15
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

J>>И это против примитивного std::vector<(.+), std::allocator<\1>>

J>>

DG>это выражение ты где собираешься применять? для поиска std::vector в произвольном C++-файле?

Это просто пример выражения с обратной ссылкой на нечто с уступчивым квантором.
Причем ссылок же несколько может быть, например std::basic_string<(.+), std::char_traits<\1>, std::allocator<\1>>.

Где можно применять конкретно это выражение, кроме С++-файлов — фильтрация того, что печатает компилятор (километровые сообщения об ошибках в шаблонном коде), дебаггер (gdb c 7-й версии можно питоном заскриптовать и сделать намного более читабельным), nm (символы в объектом файле/библитеке), typeid.name (распечатать тип чего-нть в логе программы).

Понятно, что, поскольку это выражение С++, то его грамматика известна и можно этим фактом воспользоваться, но этот регэксп можно использовать и в других контекстах, например, он сматчит "std::vector<какая-нть фигня, std::allocator<какая-нть фигня>>"
Плюс во всяких логах и прочем грамматика обычно не шибко регулярная и, что более важно, наверное — она постоянно меняется.
Поэтому писать ПЕГ, целиком описывающий грамматику лог-файла — занятие крайне неблагодарное.
Регэкспам же пофиг на грамматику, они просто найдут то, что нужно, где бы оно не находилось (т.е. .* с уступчивыми откатами), и заменят.
Т.е. я могу один и тот же фильтрующий скрипт использовать со всем подряд (и использую). Притом, это ж не единственный регэксп, у меня скрипт почти на 500 строчек, он фильтрует и STL, и добрую половину буста (которая у нас используется), и какие-то специфические для проекта CRTP...
Не уверен, что ПЕГ сможет работать в таком вот режиме.

Ну а если мы работаем в режиме в режиме — написал-нашел-забыл, то такого рода регэксп пишется на коленке за 15 секунд, в этом его главное преимущество перед полноценным, но долгим в написании ПЕГом.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[54]: З.Ы.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 31.01.11 09:06
Оценка:
J>Понятно, что, поскольку это выражение С++, то его грамматика известна и можно этим фактом воспользоваться, но этот регэксп можно использовать и в других контекстах, например, он сматчит "std::vector<какая-нть фигня, std::allocator<какая-нть фигня>>"

но ты при этом понимаешь, что этот regex может сматчит совсем не то, что ты хочешь?
например, он сматчит T1<T2<std::vector<char>, std::allocator<char>>>
при этом "какая-то фигня" будет char>
в этом-то и опасность грамматик (и regex-ов), что они часто матчат совсем не то, что хочется.
и чтобы такого не было, и приходится описывать структуру — вместо просто .*


J>Плюс во всяких логах и прочем грамматика обычно не шибко регулярная и, что более важно, наверное — она постоянно меняется.

J>Поэтому писать ПЕГ, целиком описывающий грамматику лог-файла — занятие крайне неблагодарное.

структура обычно не очень сложная, я недавно приводил (в этом треде или в соседнем) грамматику, которая описывает структуру C# — там строк 7.
соответствено для структуры лог файла будет не больше.

J>Ну а если мы работаем в режиме в режиме — написал-нашел-забыл, то такого рода регэксп пишется на коленке за 15 секунд, в этом его главное преимущество перед полноценным, но долгим в написании ПЕГом.


если при этом есть ручной контроль, то нормально, но если это целиком автоматическая замена — то замениться может что-то не то.

зы
т.е. с помощью peg проще обеспечить детерминированость и надежность разбора, а без этого некуда если код работает в автоматическом режиме без участия человека.
Re[55]: З.Ы.
От: jazzer Россия Skype: enerjazzer
Дата: 31.01.11 11:21
Оценка: 1 (1) +1
Здравствуйте, DarkGray, Вы писали:

J>>Понятно, что, поскольку это выражение С++, то его грамматика известна и можно этим фактом воспользоваться, но этот регэксп можно использовать и в других контекстах, например, он сматчит "std::vector<какая-нть фигня, std::allocator<какая-нть фигня>>"


DG>но ты при этом понимаешь, что этот regex может сматчит совсем не то, что ты хочешь?

DG>например, он сматчит T1<T2<std::vector<char>, std::allocator<char>>>
DG>при этом "какая-то фигня" будет char>
DG>в этом-то и опасность грамматик (и regex-ов), что они часто матчат совсем не то, что хочется.
DG>и чтобы такого не было, и приходится описывать структуру — вместо просто .*
Конечно же, понимаю, более того, сам наблюдал такое не раз.
Так что я, на самом деле, в скрипте использую один из расширенных перловых регэкспов из библиотеки Regexp::Common (http://search.cpan.org/~abigail/Regexp-Common-2.120/lib/Regexp/Common.pm), конкретно, $RE{balanced}{-parens=>'<>'}

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

J>>Плюс во всяких логах и прочем грамматика обычно не шибко регулярная и, что более важно, наверное — она постоянно меняется.

J>>Поэтому писать ПЕГ, целиком описывающий грамматику лог-файла — занятие крайне неблагодарное.
DG>структура обычно не очень сложная, я недавно приводил (в этом треде или в соседнем) грамматику, которая описывает структуру C# — там строк 7.
DG>соответствено для структуры лог файла будет не больше.

Она несложная, но она меняется. У нас штук 50 разных приложений + компилятор (не один) + отладчик (разные версии) + символы объектника.
сейчас у меня скрипт знать не знает обо всех этих различиях, ему пофиг откуда пришла строчка.
Грамматика — это такая вещь, которая описывает файл целиком. И это может стать лимитирующим фактором, если тебе нужен только кусочек файла, а то, вокруг кусочка, тебя либо не интересует, либо постоянно меняется.
А регэксп — это такая вещь, которая описывает кусочек файла, вне зависимости от окружения. И это тоже может стать лимитирующим фактором, если окружение важно.

J>>Ну а если мы работаем в режиме в режиме — написал-нашел-забыл, то такого рода регэксп пишется на коленке за 15 секунд, в этом его главное преимущество перед полноценным, но долгим в написании ПЕГом.

DG>если при этом есть ручной контроль, то нормально, но если это целиком автоматическая замена — то замениться может что-то не то.
"написал-нашел-забыл" подразумевает ручной контроль

DG>зы

DG>т.е. с помощью peg проще обеспечить детерминированость и надежность разбора, а без этого некуда если код работает в автоматическом режиме без участия человека.
даже если у тебя больше 50 источников, причем формат доброй половины которых постоянно меняется, и правил замены у тебя тоже под сотню?
Замучаешься же менять грамматику, чтоб подо все подходила.
Тебе ведь надо как-то скипнуть незначимую часть и запустить парсер только с правильной позиции, так?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[56]: З.Ы.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 31.01.11 11:31
Оценка:
J>Тебе ведь надо как-то скипнуть незначимую часть и запустить парсер только с правильной позиции, так?

так это примитивно делается (если не нужно перекрытие)
query := (pattern / .)*;
pattern := bla-bla;


вот если нужно перекрытие искомых образцов, то тут peg-парсер придется модифицировать
Re[57]: З.Ы.
От: jazzer Россия Skype: enerjazzer
Дата: 04.02.11 12:06
Оценка:
Здравствуйте, DarkGray, Вы писали:

J>>Тебе ведь надо как-то скипнуть незначимую часть и запустить парсер только с правильной позиции, так?


DG>так это примитивно делается (если не нужно перекрытие)

DG>
DG>query := (pattern / .)*;
DG>pattern := bla-bla;
DG>


DG>вот если нужно перекрытие искомых образцов, то тут peg-парсер придется модифицировать


Я правильно понимаю, что в результате pattern придется парсить дважды — вначале чтобы найти начало, а потом уже собственно паттерн?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[58]: З.Ы.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 04.02.11 22:52
Оценка:
J>Я правильно понимаю, что в результате pattern придется парсить дважды — вначале чтобы найти начало, а потом уже собственно паттерн?

нет, конечно. будет обычный одиночный (с точностью до откатов) проход.
Re[59]: З.Ы.
От: jazzer Россия Skype: enerjazzer
Дата: 05.02.11 04:06
Оценка:
Здравствуйте, DarkGray, Вы писали:


J>>Я правильно понимаю, что в результате pattern придется парсить дважды — вначале чтобы найти начало, а потом уже собственно паттерн?


DG>нет, конечно. будет обычный одиночный (с точностью до откатов) проход.


Не, я имею в виду, если мы хотим найти первый паттерн в строке, мы же пишем так:
query := (~pattern .)* pattern;
pattern := bla-bla;

Правильно? Т.е. паттерн матчится дважды — сначал в отрицании, потом уже в собственно матче.

А то, что ты написал
query := (pattern / .)*;
pattern := bla-bla;

Оно же сматчится в первой же позиции, нет? Как ты найдешь, когда именно сматчился паттерн? Или парсер в результате построит дерево с веткой с точкой от каждого символа, и только в каком-то месте будет pattern?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[60]: З.Ы.
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 05.02.11 08:46
Оценка:
J>Или парсер в результате построит дерево с веткой с точкой от каждого символа, и только в каком-то месте будет pattern?

да, для такой записи pattern-а будет построено дерево-"список" из узлов pattern и точка

например:
query := (pattern / .)*;
pattern := 'char';

для строки "std::vector<char, std::allocator<char>>"
даст дерево (здесь используется фича, что неименованные узлы в дерево не добавляются)
query(0, 39) std::vector<char, std::allocator<char>>
.pattern(12, 16) char
.pattern(33, 37) char


для именованной точки (c добавлением в дерево)
query := (pattern / any)*;
pattern := 'char';
any := .;


будет

query(0, 39) std::vector<char, std::allocator<char>>
.any(0, 1) s
.any(1, 2) t
.any(2, 3) d
.any(3, 4) :
.any(4, 5) :
.any(5, 6) v
.any(6, 7) e
.any(7, 8) c
.any(8, 9) t
.any(9, 10) o
.any(10, 11) r
.any(11, 12) <
.pattern(12, 16) char
.any(16, 17) ,
.any(17, 18)
.any(18, 19) s
.any(19, 20) t
.any(20, 21) d
.any(21, 22) :
.any(22, 23) :
.any(23, 24) a
.any(24, 25) l
.any(25, 26) l
.any(26, 27) o
.any(27, 28) c
.any(28, 29) a
.any(29, 30) t
.any(30, 31) o
.any(31, 32) r
.any(32, 33) <
.pattern(33, 37) char
.any(37, 38) >
.any(38, 39) >


ps
также и для именованных узлов можно настраивать — в дереве они нужны или нет.

ззы
J> Не, я имею в виду, если мы хотим найти первый паттерн в строке, мы же пишем так

если сразу не нужно всё дерево, то в парсере поддерживается итерационная (парсер переделывается в continuation-стиль) схема работы, когда после нахождения определенного узла парсер приостанавливается до последующих команд
Re[61]: З.Ы.
От: jazzer Россия Skype: enerjazzer
Дата: 05.02.11 11:18
Оценка:
Здравствуйте, DarkGray, Вы писали:

J>>Или парсер в результате построит дерево с веткой с точкой от каждого символа, и только в каком-то месте будет pattern?


DG>да, для такой записи pattern-а будет построено дерево-"список" из узлов pattern и точка


DG>(здесь используется фича, что неименованные узлы в дерево не добавляются)

DG>также и для именованных узлов можно настраивать — в дереве они нужны или нет.
Ага!
Я примерно это и имел в виду.

DG>ззы

J>> Не, я имею в виду, если мы хотим найти первый паттерн в строке, мы же пишем так

DG>если сразу не нужно всё дерево, то в парсере поддерживается итерационная (парсер переделывается в continuation-стиль) схема работы, когда после нахождения определенного узла парсер приостанавливается до последующих команд


здорово! Хорошая вещь у вас получается
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.