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

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

А что там сложного-то? Собственно, минимальная грамматика чего-то ХМЛ-подобного, без учета пространств имен, директив и всяких CDATA пишется довольно быстро. Вот, набросал за минуту:

Tag = "<" ident 
        (. var tagName = t.val; .)
        [ Attr ] 
        (
            (
                ">"
                [ tagContent ]
                "<" 
                    ident 
                    (. 
                        if (t.val != tagName)
                            raiseError();
                    .)
                ">"
            )
            |
            "/>"
        ).
        
Attr = ident "=" stringToken { Attr }.

Оно, конечно, не совсем ХМЛ, ну так минута несколько меньше "пары дней" А за пару дней вполне приличный парсер можно состряпать.

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

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

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

Вот этим регекспом
http://msdn.microsoft.com/en-us/library/system.web.regularexpressions.tagregex.aspx
я решал все задачи по разбору html, что у меня возникали.

Но, пожалуйста, заканчивайте дискуссию, никто не настаивает

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

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

Почему? Просто я не кидаюсь вообще на все новое. Так как PEG'и мне прямо сейчас не нужны — я просто дам этой технологии испытание временем. Если через некоторое время этот тул все еще жив — его можно посмотреть.

А так изучение нового должно двигаться какими-то приоритетами текущих задач.

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

Ну я и тоже с довольно общих позиций речь веду.

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

Так как сама задача разбора текста стоит редко — то в реальном мире очень часто обходятся эмпирическими средствами. Для того же ReSharper иметь реальную грамматику — очень полезно и важно. Если же мы говорим о как-то разборе, который очень ограничен и локален — то полная грамматика это overkill.

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

Еще раз — для стандартных задач писать regex не имеет смысла. А текущее поведение хорошо показывает визуализатор.

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

Ответил Владу.

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

VD>Похоже ты плохо помнишь курсы из института.

Однозначно. Ни разу это знание после университета не пригодилось.

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

Выглядит неплохо. Впрочем, если я не ошибаюсь это БНФ форма — один из самых почетных способов записывать грамматику. Только где здесь запись в одну строчку, как мне рекламировали выше по ветке? И как будет выглядеть запись захвата выражения из куска текста? Скажем мне нужно получить содержимое тэга <Items> — я представляю, как примерно будет выглядеть код с регулярными выражениями. Как будет выглядеть код на C# (там паттерн-матчинга нет, коли мы уж сравниваем именно PEG vs Regex) для PEG?

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

ВВ>Причем работает это реально *криво*. Попробуй закоментировать какой-нибудь контрол таким образом:
ВВ><!--asp:TextBox ID="TextBox1" Runat="server" --/>
ВВ>Получишь ошибку компиляции. Нормально это? Мне кажется — нет.

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

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

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

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

Не раскрыта? То же самое можно сделать с помощью семантической сети. Вот тот же пример на семантической сети с использованием Jena Rules:

[foreach_statement: strConcat("foreach", space, "(", ?expr1, ?space, "in", ?space, ?expr2, ")", space, expr3, string_to_parse) -> 
(statement:foreach_statement rdf:type statement:ForEach)
(statement:foreach_statement statement:variable ?expr1)
(statement:foreach_statement statement:collection ?expr2)
(statement:foreach_statement statement:body root_parser_rule)
]

Унифицирует строку string_to_parse, биндит ?expr1, ?expr2, ?expr3, и заносит в базу новые triples: определяет ресурс statement:foreach_statement класса statement:ForEach — это наше выражение ForEach, устанавливает для этого выражения переменную итерации statement:variable и коллекцию statement:collection, а тело цикла (exp3) матчит с root_parser_rule. Я тут конечно сильно упростил AST для наглядности.

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

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

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

Это не просто не помешало бы, это было бы убийственной фичей для некоторых задач. Кстати, посмотри на Mozart/Oz.

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

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

Я тут просто предлагал использовать более универсальный подход.
А то, что ты затронул, — это будущее IT и веба. Наступит время, и императивными способами, такими как ООП и функциональное программирование, будут решаться только ВЫЧИСЛИТЕЛЬНЫЕ задачи. Семантика будет описываться декларативно в базах знаний с использованием декларативных языков. Отделение семантики от вычислений — это есть будущее. Бизнес-системы, семантика в которых сегодня хардкодится на языках программирования, практически полностью будут основаны на онтологиях, на них же будет основываться вся интеграция (к чертям шины). Современные веб-сервисы будут заменены на семантические веб-сервисы. На откуп явам и даже (о ужас!) немерлам останутся интерфейсы пользователя и сугубо вычислительные задачи. Хаскель (бить, так сразу всех!) как низкоуровневый императивный язык, да еще не имеющий библиотек, умрет одним из первых. Ява не умрет, а превратится в императивный стандарт — благодаря кроссплафторменности, открытой архитектуре, и интеграции с семантическими инструментами.

Так что бросайте хаскель, учите декларативные языки описания семантики

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

Кэр>Почему?

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

Кэр> Просто я не кидаюсь вообще на все новое.

На вообще все — не надо. Но не глядеть на новое вовсе или глядеть в малых дозах — чревато.

Кэр> Так как PEG'и мне прямо сейчас не нужны

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

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

Кэр>Ну я и тоже с довольно общих позиций речь веду.

Ты слишком многое строишь на том, что у тебя лично нет таких задач. Причем что такое PEG ты понимаешь весьма смутно. В результате — см. выше.

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

Кэр>Так как сама задача разбора текста стоит редко

Не так редко, как тебе кажется.

Кэр>Для того же ReSharper иметь реальную грамматику — очень полезно и важно. Если же мы говорим о как-то разборе, который очень ограничен и локален — то полная грамматика это overkill.

При чем тут грамматика? Речь об инструментарии, а не о грамматике вобщем. Регексы это тоже грамматика, только куцая.

Кэр>Еще раз — для стандартных задач писать regex не имеет смысла.

Кто такие стандартные задачи? Валидация емейла — стандартная задача?

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

AVK>>Боюсь.

ВВ>А чего конкретно боишься?

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

ВВ> Ведь в этом "проекте парсера" нельзя будет использовать даже рукописные синтаксические макросы.

Что значит нельзя? У инструмента такой возможности контроля на данный момент нет.

AVK>>Ты по прежнему не понимаешь, о чем я. Неважно, вызовет оно какие то проблемы, или нет. Важно то, что никто им пользоваться не будет. Одного-двух применений недостаточно для получения качественного продукта.

ВВ>Я правда не понимаю, о чем ты. Не секрет в общем-то, что PEG-парсер добавили в Немерле не в последнюю очередь, чтобы повысить интерес к этому самому Немерле.

И сильно повысился? Хотя бы сотня пользователей PEG уже есть?

ВВ>Причем, как я понимаю, если бы Немерле был очень примитивным языком, этаким клоном C# 1.0, но с PEG-парсером, то шансов в данном случае у него было бы больше.

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

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

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

Можешь считать, что религия запрещает.

VD> Это по любому в сто раз проще чем прикручивать к проекту какой-нить генератор парсеров.

Тебе — может быть. Мне — нет.

AVK>>Зачем рантайм? Нужен кодогенератор банальный. Например в виде шаблона Т4.

VD>Можно и так.

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

VD> Только в следствии того, что он не сможет тесно взаимодействовать с основным языком будет много неудобств.

Можно и взаимодействие сделать. При помощи expression tree. Не так красиво, как со спецсинтаксисом, но вполне юзабельно. Irony видел?

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

Вполне возможно.

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

ВВ>Дело в том, что ты на основе этого опыта делаешь вывод, что XML сам по себе востребован даже без библиотек для работы с ним.

А что тут не так?

ВВ> А мне вот очень сложно представить, чтобы я стал писать парсер для XML

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

ВВ>Я бы, скорее, написал парсер JSON.

Не было тогда никакого JSON.

ВВ>При таком подходе проще сказать, что вы изобрели свой язык разметки, в чем-то похожий на XML.

Не я изобретал. И да, для пуристов полученное XMLем можноне называть.

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

Товарищ не был идиотом, и вместо траты времени на изобретение собственного формата воспользовался драфтом xml. И это, насколько я знаю, тогда совсем не было единичным случаем.

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

AVK>>ini файлы не обеспечивали всех потребностей. И, как ты правильно заметил, инструментарий для них тоже был,так что в этомплане с xml разницы никакой.

VD>Ага никакой, что косвенно подтверждает правоту мои слов и не правоту твоих.

Это как? Ты же утверждаешь, что xml используют только из-за инструментария.

VD>Какой вывод? На всех твои слова обобщать нельзя.

Но и твои тоже, не так ли?

AVK>>Задачи у них очень похожие -описание грамматик. Только мощность грамматик схемы сильно сильно меньше PEG. Поэтому схему понять заметно проще.

VD>Если так мыслить, то брэйнфак понять проще, так как его грамматика проще чем скажем у С.

Схема, в отличие от брейнфака, вполне человекочитаема и не лишена средств декомпозиции. Так что аналогия кривая.

VD>Актись. Какой на фих ХМЛ во времена дельфи 1.0?
VD> Дельфи 1.0 появилась в 1995-ом, а ХМЛ в 1996.

Вот поэтому парсеров готовых и не было.

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

VD>Если только языком.

Да нет, в реальности тоже. Ты ж сам базовую грамматику xml приводил. Рукопашный парсер с рекурсивным спуском не сильно сложнее.

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

ВВ>> Ведь в этом "проекте парсера" нельзя будет использовать даже рукописные синтаксические макросы.
AVK>Что значит нельзя? У инструмента такой возможности контроля на данный момент нет.

Нельзя значит нельзя, не работает. Все синтаксические макросы должны быть в отдельной сборке и подключаться через macro reference. Думаю, отследить появление в солюшене нового проекта совсем не сложно

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

ВВ>>Дело в том, что ты на основе этого опыта делаешь вывод, что XML сам по себе востребован даже без библиотек для работы с ним.
AVK>А что тут не так?

Я не понимаю, откуда вывод-то. Ну кто-то на твоей памяти сделал "свой ХМЛ". Причем случай единичный. Другой бы человек ХМЛ не сделал, пример я привел. Из этого касательно ХМЛ не следует ровным счетом ничего.

ВВ>> А мне вот очень сложно представить, чтобы я стал писать парсер для XML
AVK>Когда описываемые события происходили, ты еще в школу ходил. А сейчас да, сейчас парсеры XML есть везде, писать не надо.

Не надо, когда ХМЛ появился я уже школу закончил

ВВ>>Я бы, скорее, написал парсер JSON.
AVK>Не было тогда никакого JSON.

Ну ДжаваСкрипт-то был

ВВ>>При таком подходе проще сказать, что вы изобрели свой язык разметки, в чем-то похожий на XML.
AVK>Не я изобретал. И да, для пуристов полученное XMLем можноне называть.

"вы" это снова не к тебе лично. К вам я на "ты"

ВВ>> Если бы товарищ, который создал этот ваш парсер, "увлекался" бы другими форматами — или просто имел фантазию побогаче — получили бы другой язык разметки.
AVK>Товарищ не был идиотом, и вместо траты времени на изобретение собственного формата воспользовался драфтом xml. И это, насколько я знаю, тогда совсем не было единичным случаем.

А почему использование вполне логичного С-подобного формата, который априори понятен всем программистам на С и проч., это идиотизм, а реализация ХМЛ-я — на тот момент еще диковинного зверя — правильное и логичное действие?
Кстати, конфиг у этого VPN-a, в котором до хрена данных, очень удобен для чтения.

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

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

>> А я что-то не улавливаю особой разницы между PEG и регулярными
>> выражениями. Если регулярные выражения пишут, то и PEG писать будут.

MZ>RE проще PEG.

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

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

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

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

ВВ>А что там сложного-то? Собственно, минимальная грамматика чего-то ХМЛ-подобного, без учета пространств имен, директив и всяких CDATA пишется довольно быстро. Вот, набросал за минуту:

Что ты набросл то? Он говорит про времена дельфи 1.0. Тогда никакх кокоров не было. А уж для дельфи и подавно. И то что ты тут наборосал — это недоразумение, а не грамматика ХМЛ-я.

ВВ>Оно, конечно, не совсем ХМЛ,

Конечно. Точнее совсем не ХМЛ. Но нам то по фигу, да?

ВВ>ну так минута несколько меньше "пары дней" А за пару дней вполне приличный парсер можно состряпать.

По жизни это займет пару недель. В те времена да еще и на дельфи — это было бы все пара месяцев. А учитывая средний класс дельфистов может и все пол года.

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

VD>Что ты набросл то? Он говорит про времена дельфи 1.0. Тогда никакх кокоров не было. А уж для дельфи и подавно. И то что ты тут наборосал — это недоразумение, а не грамматика ХМЛ-я.

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

ВВ>>Оно, конечно, не совсем ХМЛ,
VD>Конечно. Точнее совсем не ХМЛ. Но нам то по фигу, да?

АВК в общем-то признался, что речь-то идет не об ХМЛ, а о неком ХМЛ-подобном формате.

ВВ>>ну так минута несколько меньше "пары дней" А за пару дней вполне приличный парсер можно состряпать.
VD>По жизни это займет пару недель. В те времена да еще и на дельфи — это было бы все пара месяцев. А учитывая средний класс дельфистов может и все пол года.

А, я понял. И чего я влез в самом деле. Ты же говоришь, что *дельфистам* эта задача была не под силу

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

Кэр>>Почему?

AVK>Потому что когда в руках молоток, все вокруг кажется гвоздями.

Это контруктивная форма парадокса Блаба, который в своей каноничекой форме абсолютно неконтруктивен.

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

Кэр>Вот этим регекспом
Кэр>http://msdn.microsoft.com/en-us/library/system.web.regularexpressions.tagregex.aspx
Кэр>я решал все задачи по разбору html, что у меня возникали.

Рад за тебя. Что будешь делать когда для другой задачи никто специализированного решения не напишет?

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

Кэр>Выглядит неплохо.

Вот и я о том же. Заметь, не сильно сложнее регекспов.

Кэр>Впрочем, если я не ошибаюсь это БНФ форма

Ошибешься, это PEG. Он описывает парсер, а не грамматику языка.
Но на EBNF (расширенный BNF) — это действительно похоже. Разница в трех вещах:
1. Вместо перечисления по "или" выражаемого в BNF знаком "|" в PEG-е используется оператор приоритетного выбора выражаемый знаком "\". Он работает следующим образом. Если у нас есть два правила разделенных этм оператором: "правило1 / правило2", то они обрабатываются по очереди. Причем, если первое правило сопоставится, то второе даже не будет проверяться.
2. Как и в EBNF (а так же в регулярных выражениях) в PEG есть операторы повторения "+" и "*", но в отличии от EBNF в PEG они "жадные" (как в регулярных выражениях если не ставить за ними "?").
3. В PEG есть предикаты "!" и "&". Предикаты ставятся перед некоторым правилом превращая его в правило проверки (не распознающее на самом деле этого правила). Предикат "!" означает отрицание, "&" утверждение. В приведенном выше примере предикат "!" использовался для распознавания комментариев:

!'"' any

данный код читается следующим образом: Распознать любой символ при условии, что он не является кавычкой. Казалось бы это очень похоже на конструкцию [^"] из регекспов, но на самом деле она намного мощнее, так как позволяет отрицать не отдельный символ, а плавило любой сложности. Например, для распознования содержимого сишного комментария вида /* ... */ можно использовать такое PEG-правило:

!"*/" any

А для распознавания содержимого сишной строки такое:

!(@"\" / @"\""") any

Кэр> — один из самых почетных способов записывать грамматику. Только где здесь запись в одну строчку, как мне рекламировали выше по ветке?

А зачем в одну строчку то? Ты на С++/C# тоже все в одну строчку записываешь?
И кто тебе это рекламировал?

Кэр>И как будет выглядеть запись захвата выражения из куска текста?

У все по разному. У нас — никак. Вместо этого для любого именованного правила можно определить обработчика. Короче, вот пример строчного калькулятора созданного на базе макроса PEG-парсер.

Кэр>Скажем мне нужно получить содержимое тэга <Items> — я представляю, как примерно будет выглядеть код с регулярными выражениями. Как будет выглядеть код на C# (там паттерн-матчинга нет, коли мы уж сравниваем именно PEG vs Regex) для PEG?

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