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

WH>>А у меня это один язык.

DG>очень спорное утверждение.

Один, один. Просто он расширяемый. В этом языке и if — это тоже макрос.

ДСЛ становится частью языка. В этом то и кайф.

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

WH>>Вот только нормальный человек создат проект на немерле и получит интелесенс и море других плюшек.
O>Таких "нормальных" людей можно пересчитать по пальцам

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

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

WH>Берем например парсер C#
WH>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/csharp-parser/CSharpParser/Parser.n
WH>И пишем Doc Comments на каждое правило.
WH>Типа так:
WH>

WH>            /// <summary>
WH>            /// Any character
WH>            /// </summary>
WH>      any                     = ['\u0000'..'\uFFFF'];

WH>

Ок, и что мы получаем на выходе?
Ну, чтобы сравнить с докой по Generic Language.

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

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

J>>посмотрим, как быстро он сможет парсить бэкреференсы с квантификаторами.

VD>А с какой целью они тебе нужны? Покажи правило которое без них ты не можешь разобрать.

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

You will always get what you always got
  If you always do  what you always did

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

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

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

VD>Реальная жизнь таковая, что лично я не раз запутывался в регексах размером с пол предложения что я сейчас написал.
VD>Может я конечно дебил. Тогда это все объясняет.
Я думаю, есть гораздо более простое объяснение — ты живешь в винде.
Те, кто работают в юниксе, никаких проблем с регэкспами не испытывают, потому что это повседневный инструмент, которым пользуешься по 10 раз на дню, не задумываясь.
А в винде даже чтоб с банальных CSV-файлом поработать, придется его в Excel грузить (и молиться, чтоб влез).
А для чуть более хитрых форматов (обычные лог-файлы, например — у них грамматика очень условная) — специальные смотрелки писать/покупать.
В юниксе же работа со всеми такими текстовыми файлами идет в командной строке и любая интересующая тебя информация достается набором простейших регэкспов, в результате необходимая информация достается на несколько минут, практически независимо от синтаксиса лог-файла (просто потому, что никто лог-файлы не делает рекурсивными и прочая). В подавляющем большинстве случаев ПЕГ будет для таких задач оверкиллом. Мне даже не приходит в голову задача парсинга лог-файлов, для которой ПЕГ предоставил бы лучшее решение.

You will always get what you always got
  If you always do  what you always did

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

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

J>>Ты тогда тоже разберись, что такое регэкспы и как там работает ".*", и тебе тоже все станет ясно.
J>>В ПЕГе в принципе нет понятия "последовательность любых символов с откатом" (т.е. оно есть, но не имеет смысла, так как такое правило просто съест всю строчку до конца), поэтому мне придется написать грамматику для этой последовательности, чтоб она не съела больше, чем нужно — очевидный оверкилл для большинства случаев, когда тебе нужно что-нть по-быстрому найти.

VD>Это по по незнанию лепишь. На самом деле есть и понятие, и применять его очень даже можно.
Ну да, конечно, по незнанию. То, что это знают все, кто юзает Спирит, в котором всё это именно так и было реализовано бог знает сколько лет до того, как ты узнал слово ПЕГ, ничего не значит, конечно же.

VD>Вот как, например, выглядит правило разбора сишного комментария:
VD>

VD>delimitedComment          = "/*" (!"*/" any)* "*/";

Офигеть достоинство — дважды писать "*/". С каких это пор, интересно, копи-пейст стал крут
Сравни с регэкспом

/\* .*? \*/

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

VD>any — это и есть твоя точка. Просто то что делается на "умности" "*" в регексах в ПЕГе делается на предиткатах.
Предикат — это совсем не то, что ".*". Предикаты и в регэкспах есть (твой пример с комментарием можно написать в регэкспе вот так:

/\* ((?! \*/ ) . )* \*/

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

Но ты можешь попробовать меня переубедить: напиши ПЕГ-правило с предикатом для std::vector (в ответе WH). Т.е. я допускаю, что можно написать какой-нть невменяемый трехэтажный предикат, который сможет найти вектор векторов векторов, не остановившись на ближайшем std::allocator, но и это мне сомнительно.

VD>И что характерно, на практике это намного удобнее. Ведь ".*" в регексах найдет последнее хождение того что идет за ним, а это как раз обычно никому не нужно.
На практике намного удобнее иметь выбор. Когда мне это не нужно, я юзаю нежадные кванторы. Причем цена переключения с жадной версии на нежадную — один символ после квантора. ПЕГ предлагает что-нть подобное?

You will always get what you always got
  If you always do  what you always did

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

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

N>>Дай Nemerle хотя бы под JVM, и мы начнём его рассматривать. А лучше — под LLVM или native. А на сейчас — его не существует для тех, кто хочет выйти за пределы десктопа.

VD>Уверен, что появись указанные бэкэнды у тебя найдутся новые отговорки.

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

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

VD>>Уверен, что появись указанные бэкэнды у тебя найдутся новые отговорки.

N>С чего бы вдруг?

Из опыта. Танцоры которым что-то мешает обычно после удаления того что мешает все равно находят что-то что оправдывает трудность танцев.

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

Я что хотел то сказал.

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

VD>>Это по по незнанию лепишь. На самом деле есть и понятие, и применять его очень даже можно.
J>Ну да, конечно, по незнанию. То, что это знают все, кто юзает Спирит, в котором всё это именно так и было реализовано бог знает сколько лет до того, как ты узнал слово ПЕГ, ничего не значит, конечно же.

VD>>Вот как, например, выглядит правило разбора сишного комментария:
VD>>

VD>>delimitedComment          = "/*" (!"*/" any)* "*/";
J>

J>Офигеть достоинство — дважды писать "*/". С каких это пор, интересно, копи-пейст стал крут
J>Сравни с регэкспом
J>

J>/\* .*? \*/
J>

Ты заявлял, что аналога .* нет. Ну, так что по этому вопросу ты отказываешься от своих слов?

J>Даже на такой простой задаче ПЕГ сливает в простоте использования. (Вернее сказать не "даже", а "особенно". ПЕГ хорош для парсинга сложных рекурсивных грамматик типа С++, а для простого поиска это очевидный оверкилл.)

ПЕГ:
1. Обеспечивает разбор указанной грамматики за линейное время. РЕГ-ексы с не жадным оператором "*" используют бэктрэниг, что приводит к экспоненте.
2. Позволяет использовать предикаты любой сложности, что позволят разбирать текст намного проще чем с использованием регксов.
3. В разы проще в отладке.


VD>>any — это и есть твоя точка. Просто то что делается на "умности" "*" в регексах в ПЕГе делается на предиткатах.
J>Предикат — это совсем не то, что ".*". Предикаты и в регэкспах есть (твой пример с комментарием можно написать в регэкспе вот так:
J>

J>/\* ((?! \*/ ) . )* \*/
J>

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

Ну, вот и сравни читаемость. Плюс не забывай, что для ПЕГ-а есть алгоритм обеспечивающий разбор указанной грамматики за линейное время, а для регексов такого нет.

J>Но ты можешь попробовать меня переубедить: напиши ПЕГ-правило с предикатом для std::vector (в ответе WH). Т.е. я допускаю, что можно написать какой-нть невменяемый трехэтажный предикат, который сможет найти вектор векторов векторов, не остановившись на ближайшем std::allocator, но и это мне сомнительно.

Я даже не собираюсь мериться с тобой членами. У меня априори длиннее. Если тебе интересны примеры, то просто открой грамматику C#-а. Там есть примеры любой сложности.

VD>>И что характерно, на практике это намного удобнее. Ведь ".*" в регексах найдет последнее хождение того что идет за ним, а это как раз обычно никому не нужно.
J>На практике намного удобнее иметь выбор. Когда мне это не нужно, я юзаю нежадные кванторы. Причем цена переключения с жадной версии на нежадную — один символ после квантора. ПЕГ предлагает что-нть подобное?

Да, выбор хорошая штука. Жаль что ты его не имеешь. В прочем, тебе явно не нужно. Каменный молоток тебя явно устраивает.

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

VD>Нормальных людей (без кавычек) крайне мало. Миром правит посредственность, лень и глупость.
Понятно. Еще один "непонятый художник".

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

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

VD>>>Это по по незнанию лепишь. На самом деле есть и понятие, и применять его очень даже можно.
J>>Ну да, конечно, по незнанию. То, что это знают все, кто юзает Спирит, в котором всё это именно так и было реализовано бог знает сколько лет до того, как ты узнал слово ПЕГ, ничего не значит, конечно же.

VD>>>Вот как, например, выглядит правило разбора сишного комментария:
VD>>>

VD>>>delimitedComment          = "/*" (!"*/" any)* "*/";
J>>

J>>Офигеть достоинство — дважды писать "*/". С каких это пор, интересно, копи-пейст стал крут
J>>Сравни с регэкспом
J>>

J>>/\* .*? \*/
J>>

VD>Ты заявлял, что аналога .* нет. Ну, так что по этому вопросу ты отказываешься от своих слов?
Я не заявлял, что аналога нет. Потому что "аналог" можно очень широко понимать, что ты и делаешь. Я заявлял, что функциональности ".*" в ПЕГе нет. И пока ты мне не продемонстрируешь ПЕГ, парсящий std::vector — твое утверждение о том, что функциональность такая есть, продолжит висеть в воздухе.


J>>Даже на такой простой задаче ПЕГ сливает в простоте использования. (Вернее сказать не "даже", а "особенно". ПЕГ хорош для парсинга сложных рекурсивных грамматик типа С++, а для простого поиска это очевидный оверкилл.)

VD>ПЕГ:
VD>1. Обеспечивает разбор указанной грамматики за линейное время. РЕГ-ексы с не жадным оператором "*" используют бэктрэниг, что приводит к экспоненте.
Наоборот, это жадные приводят к экспоненте, и то в патологических случаях. Ты разберись сначала, что такое жадные и нежадные кванторы, а потом пиши. Плюс в большинстве случаев использования регэкспов скорость вообще не является приоритетом. Особенно если это вменяемые регэкспы, а не какой-нибудь бред в стиле ".*.*.*".
VD>2. Позволяет использовать предикаты любой сложности, что позволят разбирать текст намного проще чем с использованием регксов.
Регэкспы тоже позволяют использовать предикаты любой сложности.
VD>3. В разы проще в отладке.
Измерение разов в студию.

VD>>>any — это и есть твоя точка. Просто то что делается на "умности" "*" в регексах в ПЕГе делается на предиткатах.
J>>Предикат — это совсем не то, что ".*". Предикаты и в регэкспах есть (твой пример с комментарием можно написать в регэкспе вот так:
J>>

J>>/\* ((?! \*/ ) . )* \*/
J>>

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

VD>Ну, вот и сравни читаемость. Плюс не забывай, что для ПЕГ-а есть алгоритм обеспечивающий разбор указанной грамматики за линейное время, а для регексов такого нет.
Влад, ты вообще вдумываешься в то, что тебе пишут, или лишь бы ляпнуть? Ну да это твой стиль, чего я удивляюсь.
На всякий случай, для тех, кто в танке и не может посмотреть десятью строчками выше — для того, чтоб распарсить сишный комментарий, достаточно регэкспа /\*.*?\*/, в котором, в отличие от ПЕГа, не нужно писать */ дважды.

J>>Но ты можешь попробовать меня переубедить: напиши ПЕГ-правило с предикатом для std::vector (в ответе WH). Т.е. я допускаю, что можно написать какой-нть невменяемый трехэтажный предикат, который сможет найти вектор векторов векторов, не остановившись на ближайшем std::allocator, но и это мне сомнительно.

VD>Я даже не собираюсь мериться с тобой членами. У меня априори длиннее. Если тебе интересны примеры, то просто открой грамматику C#-а. Там есть примеры любой сложности.
Ой, ты что, так расстроился за ПЕГ, что воспринял его критику в свой адрес и решил, что кого-то интересует длина твоего члена? Ну прости, пожалуйста, я не думал, что ты такой чувствительный. Конечно же, у тебя длиннее, ты же модератор. И грудь у тебя априори больше, на случай, если ты девочка.
А вопрос тем временем остается открытым — как написать на ПЕГе правило, которое сматчит вектор, не задавая грамматики для элемента вектора.
Но ты не волнуйся, я этот вопрос не тебе первому задаю, и до сих пор никто решения не представил. Подозреваю, что это потому, что его в рамках ПЕГа не существует. Так что можешь спокойно продолжать свои априорные измерения.

VD>>>И что характерно, на практике это намного удобнее. Ведь ".*" в регексах найдет последнее хождение того что идет за ним, а это как раз обычно никому не нужно.
J>>На практике намного удобнее иметь выбор. Когда мне это не нужно, я юзаю нежадные кванторы. Причем цена переключения с жадной версии на нежадную — один символ после квантора. ПЕГ предлагает что-нть подобное?

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

You will always get what you always got
  If you always do  what you always did

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

VD>Так вот ПегГраммар делает тоже самое. Он оптимизирует эти самые 99% так как только может. Для разбора регулярной части используется ДКА (причем не табличный, а генерированный). Для нивилирования откатов используется частичная мемоизация. Ну, и сам он написан так чтобы не тратить такты зря. Первое что было предложено — это использовать в качестве позиции и информации об успехе парсинга одну переменную типа int. Почему-то большинство тех кто реализует ПЕГ до этого не додумываются. Далее была сделана отимизация правил (переписывание) и инлайнинг. Потом ДКА и мемоизация. В купе это дало очень приличную скорость. Многие в ручную написанным парсером такую обеспечить не могут.

И всё же интересно. Какая у вас получалась разница между полной мемоизацией и ее отсутствием, приблизительно?

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

VD>А это феномен, кстати! Люди не боятся кривых сложных языков которые не конкурируют с их любимым языком общего назначения. Но как огня боятся языка который может заменить им их любимый язык.

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

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

K>И всё же интересно. Какая у вас получалась разница между полной мемоизацией и ее отсутствием, приблизительно?

Дикая. Полная мемоизаци да еще и реализованная в лоб (на хэш-таблице) — это однозначный тормоз.

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

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

Кстати, а на каких примерах PEG будет давать экспоненциальную сложность? Или хотя бы полиномиальную?

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

ВВ>>Мне интересно:
ВВ>>- Пакрат реально дает O(n) или это только в теории, а на практике это не O(n)? Если да, то почему так происходит.
ВВ>>- Если излишняя мемоизация вредна, но по каким критерием определяется, что мемоизировать, а что нет?

VD>Ответ таков. Ты не понимаешь что такое линейное время.

Это не ответ. Я задал вполне конкретные вопросы вроде как. Речь идет не о сферических конях в вакууме, а о пакрате. За основу берется паркатовская модель, мемоизирующая все и имеющая O(n). Сократив мемоизацию, мы теряем O(n), но при этом в реальности парсер начинает работать быстрее. Почему так происходит? Короче — в каких случаях излишняя мемоизация вредна? Как вы определяете, что мемоизировать, а что нет?

S>Чтобы PEG заменил регекспы, нужно, чтобы он стал
S>а) очень-очень распространён. Чтобы можно было за $28 купить или за $7.99 скачать книгу O'Reilly про него, где всё обсосано до мелочей. Чтобы библиотеки с его поддержкой (совместимые по способу использования!!!) были широко доступны на всех основных языках разработки.
S>б) применим для мелких масштабов. Чтобы можно было применять его для проверки, поиска и замены коротких цепочек.
S>в) применим для непрограммистов. Чтобы "грамматику" или что там у него вместо строки регекспа можно было скормить в мою программу через несложный UI (или конфиг-файл), не привлекая IDE c code completion и билд-машину.

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

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

K>Кстати, а на каких примерах PEG будет давать экспоненциальную сложность? Или хотя бы полиномиальную?

Экспоненту получить вообще сложно. Хреновые показатели будут на грамматиках с большими общими префиксами и на грамматиках чей класс очень сильно и постоянно отличается от LL(1). Короче, на грамматиках для разбра которых нужны частые и глубокие откаты.

Вот только 99% языков как раз имеют почти LL(1)-грамматики. Например, C# имеет грамматику которую можно на 95% переписать в LL(1). Но там есть сложности вроде эвристик связанных с оператором приведения типов (конфликтующим со скобками и вызовом функций), оператор ?: и ? в налабл-типах и некоторое количество дурной фигни. PEG позволяет разрулить эти неоднозначности с помощью предикатов (благо они ничем не ограничены), а вот у автоматных парсеров эти эвристики вызывают ужасные проблемы.
Вот примерный список конфликтов в грамматике шарпа.
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/csharp-parser/CSharpParser/Parser.n#199
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/csharp-parser/CSharpParser/Parser.n#208
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/csharp-parser/CSharpParser/Parser.n#260
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/csharp-parser/CSharpParser/Parser.n#329
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/csharp-parser/CSharpParser/Parser.n#333
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/csharp-parser/CSharpParser/Parser.n#405

Можешь сравнить это с общим количеством правил.

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

ВВ>Это не ответ. Я задал вполне конкретные вопросы вроде как. Речь идет не о сферических конях в вакууме, а о пакрате. За основу берется паркатовская модель, мемоизирующая все и имеющая O(n). Сократив мемоизацию, мы теряем O(n), но при этом в реальности парсер начинает работать быстрее. Почему так происходит?

А что ответ разве не очевиден? Мемоизация дает очень большой оверхэд. Выигрыш от нее есть только если она предотвращает относительно глубокие откаты, а проигрыш на каждом символе. В итоге на обычных языках, которые все как они близки к LL(1) толку от мемоизации почти нет, а затраты на нее есть всегда и они очень значительны.

ВВ>Короче — в каких случаях излишняя мемоизация вредна? Как вы определяете, что мемоизировать, а что нет?

Тестами и логическим выводом.

1. Мы не используем таблицы мемоизации, а используем обычные поля класса (по одному на правило). Это не позволяет производить мемоизацию для разных позиций разбора (только для последней позиции в которой производилась попытка разбора правила).
2. Мемоизация делается только для правил для которых есть методы-обработчики.

Кроме того я нигде не говорил, что на практике мемоизация дает серьезный выигрыш в скорости. Добавление частичной мемоизации ускорило парсер C#, но не в разы, а на проценты. Тотальная же мемоизация замедляла его в разы.

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


M>И еще чтобы синтаксис был вехде единым. PCRE настолько распространены, что никто и не думает, что писать можно и по другому. А с PEGом я уже три разных синтаксиса видел И наверняка еще найду
Это я и имел в виду под "совместимым способом использования".