[Голосование] Понимаете ли вы формальные грамматики? - Философия программирования

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

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

Отлаживать регэкспы просто? Я знаю только один способ — тесты, этот же способ один в один работает с грамматиками.

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

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

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

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

К примеру задачи которые вспомнились легко: разбор сиквела, применение пользовательских фильтров, декларативные правила авторизации. Для всех них я нашел альтернативные решения, либо свел ограничил грамматику регулярной. Хотя все они решились бы гораздо изящнее и были бы мощнее если бы я легко мог создать AST из строки.

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

P.S. К сожалению есть и обратный эффект, только изучив инструмент, зачастую его используют совсем не по делу

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

VD>>http://rsdn.ru/poll/2615.aspx

LP>VladD2, для языка реально было бы полезно, если бы в нем была встроенная семантика. Варианты:
LP>1. Реализовать подмножество Пролога
LP>2. Реализовать поддержку семантической сети, причем не какой-нить, а w3c, как-то: описание rdf-троек + встроенный reasoner для Semantic Web, например прикрутить что-то вроде http://clarkparsia.com/pellet/. Этот вариант имхо предпочтительнее, так как за Semantic Web — будущее (пусть и не очень близкое).

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

LP>Я думаю, все это можно сделать в Nemerle существующими средствами, без расширения языка.

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

Что касается использования формальных грамматик, то с недавнего времени для немерле есть макрос позволяющий генерировать парсеры на базе PEG-грамматик. Так что на текущей версии Nemerle можно в том числе пользоваться тем о чем идет речь в данном голосовании.

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

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

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

ТЗИ>А вообще, вы сперли мою идею.

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

Это даже не твоя идея. Она уже проскакивала раз дцать. Даже в Перл 6 что-то похожее (только для расширений) вроде бы делают. Есть даже прототипы. Правда совершенно не пригодные для использования на практике.

ТЗИ>Ну что ж, посмотрим, что у вас получится.

Дык может лучше присоединиться? Здесь идет обсуждение новых фич Nemerle 2. Можно начать с присоединения к обсуждению.

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

MZ>RE проще PEG.

Да ну? То то я на PEG описываю грамматики с пол пинка, а на регекспах постоянно спотыкаюсь.

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

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

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

Z>Отлаживать регэкспы просто? Я знаю только один способ — тесты, этот же способ один в один работает с грамматиками.

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

Z>P.S. К сожалению есть и обратный эффект, только изучив инструмент, зачастую его используют совсем не по делу

.

Это эффект Блаба.

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

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

>> С целью сбора статистики. Интересно готов ли народ использовать на
>> практике подобные вещи. Регекспы, при всей их убогости, используются по

MZ>Это типа DSL-и строить ?

И они в том числе. PEG или EBNF помогли бы упростить решение массы задач связанных с разбором строк. В прочем, очень часто эти задачи (не осмысленно) являются частью пути программиста к DSL-ям.

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

G>Ну как минимум сделать опцией ignore whitepace, чтобы между любыми двумя токенами подразумевалось любое количество пробельных символов (в том числе нулевое если получится).

G>Кроме того нужна какая-нить "стандартная библиотека парсеров", чтобы можно было использовать в своих макросах. Обязательно что-то вроде "параметризованных парсеров" и парсер списка в стандартной бибилиотеке.

Если интересно, поглядите вот эти обсуждения:
http://rsdn.ru/forum/nemerle/3847445.aspx
http://rsdn.ru/forum/nemerle/3851198.aspx

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

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

Z>Отлаживать регэкспы просто? Я знаю только один способ — тесты, этот же способ один в один работает с грамматиками.

Отлаживать регэкспы очень сложно. Нет дебага/трэйса. Без специальных средств вроде того же RegexBuddy (или как его там), который может визуализировать структуру регекспа — еще сложнее.

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

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

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

Z>То же самое и с удобным описанием грамматики, легкость решения подобных задач спровоцирует мозг на еще один угол зрения на каждую проблему. Я убежден, что задачи для PEG найдутся очень быстро. Разбор различных текстов реально довольно частая ситуация. То, что они часто образуют грамматику мы просто не замечаем. За неимением удобного инструмента кто-то пытается использовать регэкспы, кто-то сразу видит нерегулярность грамматики и пытается обойтись без разбора вообще.

Кто-то просто юзает XML как вид текстового ввода, который не нужно структурировать и не сильно страдает. Очень редко на вход программы попадает сырой текст, который нужно разобрать. А когда попадает, то семантический анализ занимает гораздо большую часть, чем синтаксический — например, как в search engine.

Z>К примеру задачи которые вспомнились легко: разбор сиквела, применение пользовательских фильтров, декларативные правила авторизации. Для всех них я нашел альтернативные решения, либо свел ограничил грамматику регулярной. Хотя все они решились бы гораздо изящнее и были бы мощнее если бы я легко мог создать AST из строки.

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

Z>Вопросы как разобрать нерегулярную грамматику с помощью регулярных выражений возникают в .net примерно раз в месяц.

В основном — как распарсить HTML. Иногда как распарсить дату. Для этого нужен FAQ, потому что для этих задач есть стандартные решения, а не поддержка PEG грамматик.

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

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

>>> С целью сбора статистики. Интересно готов ли народ использовать на
>>> практике подобные вещи. Регекспы, при всей их убогости, используются по

MZ>>Это типа DSL-и строить ?

VD>И они в том числе. PEG или EBNF помогли бы упростить решение массы задач связанных с разбором строк. В прочем, очень часто эти задачи (не осмысленно) являются частью пути программиста к DSL-ям.

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

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

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

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

О чем ты?

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

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

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

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

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

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

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

Z>>Отлаживать регэкспы просто? Я знаю только один способ — тесты, этот же способ один в один работает с грамматиками.

Кэр>Отлаживать регэкспы очень сложно. Нет дебага/трэйса. Без специальных средств вроде того же RegexBuddy (или как его там), который может визуализировать структуру регекспа — еще сложнее.

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

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

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

VD>>>http://rsdn.ru/poll/2615.aspx

LP>>VladD2, для языка реально было бы полезно, если бы в нем была встроенная семантика. Варианты:
LP>>1. Реализовать подмножество Пролога
LP>>2. Реализовать поддержку семантической сети, причем не какой-нить, а w3c, как-то: описание rdf-троек + встроенный reasoner для Semantic Web, например прикрутить что-то вроде http://clarkparsia.com/pellet/. Этот вариант имхо предпочтительнее, так как за Semantic Web — будущее (пусть и не очень близкое).

VD>Против пролога ничего не имею. Вещь полезная. В полезности прикручивания к языку Semantic Web (как в прочем и вообще в полезности Semantic Web) я сильно сомневаюсь.

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

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

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

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

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

Z>О чем ты?

Ты уже забыл в каком разговоре родилась идея NRails?

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

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

Z>>О чем ты?

VD>Ты уже забыл в каком разговоре родилась идея NRails?

Видимо забыл, какие неудачи имеются ввиду?

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

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

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

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

"Кэр" wrote:

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

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

Posted via RSDN NNTP Server 2.1 beta

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

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

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

Posted via RSDN NNTP Server 2.1 beta

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

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

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

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

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

LP>

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кэр>Хм, очень интересно. А зачем тогда использовать PEG вместо регулярных выражений?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

Кэр>У нас во всем продукте регекспы встречаются только в одном месте — где нужно SQL скрипты попилить по разделителю "GO". Все!

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

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

http://www.google.ru/search?sourceid=chrome&ie=UTF-8&q=site:rsdn.ru/forum/dotnet+%D1%80%D0%B5%D0%B3%D1%83%D0%BB%D1%8F%D1%80%D0%BD%D0%BE%D0%B5+regex

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

Кэр>>У нас во всем продукте регекспы встречаются только в одном месте — где нужно SQL скрипты попилить по разделителю "GO". Все!

AVK>По разделителю GO в общем случае регексами не попилишь, а в частном, когда GO всегда начинается с начала строки и строковые константы с GO в начале строки отсутствуют, регексы тут явно из пушки по воробьям.

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

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

AVK>http://www.google.ru/search?sourceid=chrome&ie=UTF-8&q=site:rsdn.ru/forum/dotnet+%D1%80%D0%B5%D0%B3%D1%83%D0%BB%D1%8F%D1%80%D0%BD%D0%BE%D0%B5+regex

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

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

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

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

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

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

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

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

И рядом недостатков. Очень серьезных недостатков.

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

Далеко не все.

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

Очень зря ты сомневаешься.

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

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

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

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

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

LP>>

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

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

ТЗИ>А в чем профит?

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

Здравствуйте, gandjustas, Вы писали:
Кэр>>Применяются крайне редко.
G>Уверен?
А как часто и какие выражения вам приходиться разбирать?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

NB>сыр-бор ради возможности использовать в языке ДСЛ.
NB>ну а улучшение в том, что PEG позволяет описывать более широких класс грамматик чем регэкспы.
Насколько часто в проектах нужен настолько сложный dsl, думаю большинство случаем покрывается банальным флуент интерфейсом.

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

D>Здравствуйте, gandjustas, Вы писали:
Кэр>>>Применяются крайне редко.
G>>Уверен?
D>А как часто и какие выражения вам приходиться разбирать?

Я пару раз пользовался dsl для различных задач, относительно недавно столкнулся с парсингом слабосруктурированных данных для укладывания в реляционную БД.

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

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

NB>>сыр-бор ради возможности использовать в языке ДСЛ.
NB>>ну а улучшение в том, что PEG позволяет описывать более широких класс грамматик чем регэкспы.
D>Насколько часто в проектах нужен настолько сложный dsl, думаю большинство случаем покрывается банальным флуент интерфейсом.

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

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

ТЗИ>И чего тут сложного-то?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

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

NB>насколько часто программе нужно получать данные извне?
Практически всегда, только как это связано с dsl?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

NB>>насколько часто программе нужно получать данные извне?
D>Практически всегда, только как это связано с dsl?

как корректность полученных данных проверяете?

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

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

NB>>>насколько часто программе нужно получать данные извне?
D>>Практически всегда, только как это связано с dsl?

NB>как корректность полученных данных проверяете?
Валидацией?
Давайте от вакуума перейдем к чему то конкретному, что за данные вы предлагаете получать и как дслем их проверять.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

NB>>>>насколько часто программе нужно получать данные извне?
D>>>Практически всегда, только как это связано с dsl?

NB>>как корректность полученных данных проверяете?
D>Валидацией?
D>Давайте от вакуума перейдем к чему то конкретному, что за данные вы предлагаете получать и как дслем их проверять.

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

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

NB>ну те же формулы в экселе.
И как часто нужно изобретать свой движок для формул?
NB>или конфиги.
Xml, yaml, json или любой дт язык, или вообще не вводить лишние сущности а скомпилировать
и подргузить кусок кода основного языка. Насколько необходимо придумывать еще что то?
NB>натравливаешь парсер и получаешь нужный результат или ошибку если данные не корректны.
Я представляю что такое внешний дсл, но я сомниваюсь что он нужен хотя бы 1% проектов которые старнуют каждый день.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

NB>>ну те же формулы в экселе.
D>И как часто нужно изобретать свой движок для формул?
NB>>или конфиги.
D>Xml, yaml, json или любой дт язык,

которые тоже являются дсл.

D>или вообще не вводить лишние сущности а скомпилировать
D>и подргузить кусок кода основного языка. Насколько необходимо придумывать еще что то?

ок. зайдем с другой стороны.
ты регэкспы используешь? зачем?

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

NB>которые тоже являются дсл.
И которые придумываются один раз в десять лет.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

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

какие задачи?

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

.

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

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

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

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

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

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

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

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

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

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВВ>На неделю?!

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

Вручную без опыта? Да легко!

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

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

"тем, что их обычно записывают в одну строчку без пробелов" + отсутствуют средства абстрагирования (функции или правила).

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

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

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

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

ВВ>Сам ПЕГ парсер сделан в виде макроса. И использовать его можно только из Немерле, да.

Ну так я именно об этом и говорю.

ВВ> С другой стороны, что отсюда вытекает?

Вытекает отсюда очень простой момент — количество использующих Немерле, помноженное на процент тех, кому нужен PEG даст на выходе величину < 10 человек.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

Ну а дальше можешь и не продолжать.

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

Готовый парсер? Слабое утешение.

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>LL/LR — это терминалогия из области посторения ДКА по грамматикам (т.е. парсеров на их основе)

Не только. Мощность грамматик тоже так называют. Определение очень простое — грамматика мощностью LL(k) это такая грамматика, которая может быть разобрана LL(k) парсером.

VD>ПЕГ же разбирает любые грамматики которые можно разобрать методом рекурсивного спуска с откатами

Вот поэтому я и написал "примерно". В LL/LR(*) укладываются почти все реальные КС грамматики.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

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

Ну докажи тогда, что Летающего Макаронного Монстра не существует.

VD>Я не знаю что такое базовый слой.

Теги, атрибуты, текст.

VD> Но сам ХМЛ отнюдь не прост.

Спасибо, КО.

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

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

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

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

VD>Я бы так не сказал.

А я сказал.

VD> Да и задачи у них все же разные.

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

VD>Начиная с версии 2.0 дельфи прекрасно позволяет пользоваться MSXML.

Я про 1.0. И в 2.0 с СОМом не все было шоколадно, оно там через хаки юзалось. Нормальная поддержка появилась в 3.0.

VD>На коленке приличный парсер написать трудно.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

AVK>Вытекает отсюда очень простой момент — количество использующих Немерле, помноженное на процент тех, кому нужен PEG даст на выходе величину < 10 человек.

Я, честно говоря, тебя не понимаю. Подавляющее большинство генераторов парсеров "для C#" работают через внешний DSL. Внешний DSL — это уже не код на C#, это некий язык, который также надо учить, причем как правило не имеющий никакой поддержки со стороны IDE. Т.е. работать с этим DSL ты будешь как с текстом. Однако же это не останавливает людей при использовании генераторов парсеров.

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

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

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

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

Забавно. А выше ты критиковал Кэра за "технологии парсинга", которые не работают для всех случаев.
Я правильно понимаю, что этот ваш парсер в продакшин коде не использовался?

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

ВВ>Так, повторюсь, какая проблема?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

ВВ>Забавно. А выше ты критиковал Кэра за "технологии парсинга", которые не работают для всех случаев.

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

ВВ>Я правильно понимаю, что этот ваш парсер в продакшин коде не использовался?

Какой мой парсер? Ты, сдается мне, что то странное себе нафантазировал. Перечитай еще раз внимательно ветку.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>>Я правильно понимаю, что этот ваш парсер в продакшин коде не использовался?

AVK>Какой мой парсер? Ты, сдается мне, что то странное себе нафантазировал. Перечитай еще раз внимательно ветку.

Э, парсер ХМЛ. Готового в Дельфи не было, писали свой, который понимал только "базовый слой" ХМЛ. Т.е., проще говоря, парсил ХМЛ документ неправильно и мог бы свалиться, если б в документе попались те же пространства имен. Что я нафантазировал?

И, согласно твоим же выкладкам, такой ограниченный инструмент в качестве "внешней тулзы" лучше не использовать.

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

AVK>Проблема в том, что генератор макросов это маленькая тулза с очень ограниченной грамматикой, чего не скажешь о Nemerle.

Я, собственно, не высказываю тут позицию какого-либо "лагеря". Или у тебя баннер у меня в подписи смущает? Грамматика у Немерле, конечно же, более сложная, однако я действительно не понимаю, как это может помешать в данном случае. Собственно, на Немерле придется описывать лишь семантические действия, и грамматика там весьма ограниченная. Вообще на Немерле можно писать "как на C#" — и разница будет минимальной.

Ты боишься того, что кто-то начнет в таком "проекте парсера" использовать Немерле "на полную катушку"? В том, что пару библиотек из рантайма Немерле придется распространять вместе с приложением? В том, что для парсера всегда придется выделять отдельный проект?

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

Смысл спора не в том, что кого-то в чем убедить — это занятие малоперспективное. Ты же немерлевый PEG-парсер в реальной жизни тоже не использовал, так что все твои опасения — умозрительные. Впрочем, как и "вера" в то, что никаких принципиальных проблем использовать такой парсер из C# не будет.

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

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

ВВ>Собственно, на Немерле придется описывать лишь семантические действия, и грамматика там весьма ограниченная.

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

ВВ> Вообще на Немерле можно писать "как на C#" — и разница будет минимальной.

Контроля нет.

ВВ>Ты боишься того, что кто-то начнет в таком "проекте парсера" использовать Немерле "на полную катушку"?

Боюсь.

ВВ>Смысл спора не в том, что кого-то в чем убедить — это занятие малоперспективное. Ты же немерлевый PEG-парсер в реальной жизни тоже не использовал

И не буду.

ВВ>, так что все твои опасения — умозрительные.

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

ВВ>Разница лишь в том, что я-то пытаюсь объяснить, почему на мой взгляд, использование такого парсера в C#-проектах не вызовет никаких проблем.

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

ВВ> Твои же опасения мне попросту не понятны, т.к. ты о них и не говоришь, собственно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

AVK>>Какой мой парсер? Ты, сдается мне, что то странное себе нафантазировал. Перечитай еще раз внимательно ветку.

ВВ>Э, парсер ХМЛ. Готового в Дельфи не было, писали свой, который понимал только "базовый слой" ХМЛ. Т.е., проще говоря, парсил ХМЛ документ неправильно и мог бы свалиться, если б в документе попались те же пространства имен. Что я нафантазировал?

Больше половины. Во-первых парсер не мой, я его просто видел в чужом проекте. Во-вторых ему не могли попасться никакие пространства имен, потому что источником xml был тот же самый продукт. В-третьих там никто и не обещал полную поддержку xml, только его сабсет, полностью покрывающий потребности. И в рамках этого сабсета никаких ограничений на применяемые конструкции не было. А полную поддержку всех фич xml там никто и не обещал (в то время как бы сам стандарт не был в стадии драфта).

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

Я и не утверждал, что именно *твой*. Под "вами" имелись в виду некие дельфисты, работавшие в Дельфи 1.0.

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

Дело в том, что ты на основе этого опыта делаешь вывод, что XML сам по себе востребован даже без библиотек для работы с ним. А мне вот очень сложно представить, чтобы я стал писать парсер для XML — неважно, ограниченный или "безграничный", — если бы мне потребовал формат для хранения иерархических структур, а никаких готовых библиотек под это дело просто не было бы.
Я бы, скорее, написал парсер JSON. Хотя бы просто потому что он проще, и можно сделать полноценный парсер за приемлимое время, а не поддерживать некий "базовый слой". Да и, кстати, во многих случаях JSON вдобавок и куда читабельнее.

Вся мощь XML как раз в библиотеках и, можно сказать, в сопутствующих технологиях, в тех самых XSD, XSLT. Убери это — и ничего не останется.

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

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

Вот у меня, например, стоит тут CheckPoint VPN — у него конфиг написан на некоем сабсете С, в чем-то похоже на JSON, но не до конца. И приложение явно корнями из 90-х, когда с XML-ем не носились так, как сейчас. Вот тоже ничего себе формат. И я прекрасно понимаю логику людей, создавших этот конфиг — ведь они использовали синтаксис, который уже понятен и привычен всем разработчикам на проекте.
Однако, какой из этого можно сделать вывод? Да никакого

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

ВВ>>Ты боишься того, что кто-то начнет в таком "проекте парсера" использовать Немерле "на полную катушку"?
AVK>Боюсь.

А чего конкретно боишься? Ведь в этом "проекте парсера" нельзя будет использовать даже рукописные синтаксические макросы. Боишься кода в функциональном стиле?
Нет, мне правда хочется понять.

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

Я правда не понимаю, о чем ты. Не секрет в общем-то, что PEG-парсер добавили в Немерле не в последнюю очередь, чтобы повысить интерес к этому самому Немерле. И, соответственно, увеличить количество людей, которые Немерле используют. Ты говоришь, что эта идея обязательно потерпит фиаско. Причем, как я понимаю, если бы Немерле был очень примитивным языком, этаким клоном C# 1.0, но с PEG-парсером, то шансов в данном случае у него было бы больше. Однако же какие грабли таит в себе Немерле? Использование макросов легко проконтролировать. Несинтаксические макросы, на мой взгляд, вообще никакой опасности в себе не несут. Ну просто компайл-тайм функции. В C# тоже много чего в компайл-тайме происходит. Где угроза?

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

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

AVK>Готовый парсер? Слабое утешение.

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

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

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

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

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

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

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

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

AVK>Не только. Мощность грамматик тоже так называют. Определение очень простое — грамматика мощностью LL(k) это такая грамматика, которая может быть разобрана LL(k) парсером.

Ага. А вот грамматику разбираемую LL(*) как назвать? А грамматику разбираемую PEG-ом? А меж тем она у них идентичная.

VD>>ПЕГ же разбирает любые грамматики которые можно разобрать методом рекурсивного спуска с откатами

AVK>Вот поэтому я и написал "примерно". В LL/LR(*) укладываются почти все реальные КС грамматики.

Нет никакого LR(*). GLR мощнее PEG просто потому что позволяет разбирать неоднозначные грамматики. А мощьность LL(*) и PEG равны. По сути LL(*) — это прикручивание автомата к PEG-у.

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

AVK>Ну докажи тогда, что Летающего Макаронного Монстра не существует.

А мне не надо. Я же утверждал обратного.

VD>>Я не знаю что такое базовый слой.

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

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

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

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

VD>>Я бы так не сказал.

AVK>А я сказал.

ОК. Сойдемся что для тебя это так, а для меня — нет.
Какой вывод? На всех твои слова обобщать нельзя.

VD>> Да и задачи у них все же разные.

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

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

VD>>Начиная с версии 2.0 дельфи прекрасно позволяет пользоваться MSXML.

AVK>Я про 1.0. И в 2.0 с СОМом не все было шоколадно, оно там через хаки юзалось. Нормальная поддержка появилась в 3.0.

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

VD>>На коленке приличный парсер написать трудно.

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

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

Здравствуйте, 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 не имеет смысла.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

AVK>>Боюсь.

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

Здравствуйте, 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# это пока что никак не будет выглядеть, так как я пока не знаю о решениях для шарпа которые можно использовать прямо из кода. Но в принципе оно может мало чем отличаться от того что ты делаешь с регулярными выражениями. Разве что ты сможешь все же произвести декомпозицию своего паттерна, если он станет сложным.

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

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

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

Тогда остается только кушать то что есть — кактус.

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

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

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

AVK>Я бы сказал нужно,

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

AVK>если тебе интересно чтобы этим хоть кто то пользовался.

Мне не хочется. У меня уже есть. Я тут другим идеи подкидываю.

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

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

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

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

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

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

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

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

Нет. Мои слова не зависят от моего мнения. Они являются чистой индукцией.

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

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

Я ее видел. Но вот описывать ее мне тяжело.

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

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

Не было не только парсеров, но и самого ХМЛ-я. Уверен, что о ХМЛ-е ты узнал примерно в то же время когда узнал о дотнете. А к этому времени было уже и Дельфи 2, и даже 3, которые работали с КОМ-ом, так что можно было спокойно взять МС-ный парсер.

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

Сольно. Раз эдак в 10. Его без подготовки мало кто быстро написать может. А те кто смогут скорее всего не будут, так как другими задачами занимаются.

Вот ты лично хотя бы один ХМЛ-парсер написал?

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

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

Вы меня тут так процитировали, что я даже растерялся

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

Я просто прагматично подхожу к процессу.

Кэр>> Просто я не кидаюсь вообще на все новое.
AVK>На вообще все — не надо. Но не глядеть на новое вовсе или глядеть в малых дозах — чревато.

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

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

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

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

Мне ответили, что PEG — нужны там, где нужны regex, что мы еще обсудим с Владом ниже по ветке. И хотя что такое PEG я понимаю действительно смутно — regex мне нужны редко

Кэр>>Так как сама задача разбора текста стоит редко
AVK>Не так редко, как тебе кажется.

Дык возвращаемся к исходному вопросу. Я утверждаю, что разбор текста важен:
1. Проверка шаблона (различные верификаторы). Для большинства стандартных случаев уже просто есть regex, которые работают.
2. Эмпирическое выделение/разделение кусков текста. Выкусить конкретное значение аттрибута, или имя класса, или еще что-то в таком духе. Или порезать тот же SQL на блоки команд. Полная грамматика языка тут не нужна. Хватает эвристик на пару с regex'ами.
3. Полноценный разбор текста, построение AST, анализ структур и прочее. Необходима грамматика — с ней должно быть удобно работать. Этот пункт важен для компилятора Немерле, важен для РеШарпера, важен для тех несчастных душ, которые на волне хайпа будут пытаться свои конфиги записывать как DSL. Совершенно неважен для большинства реальных задач инженера.

Что я пропустил? Что тут не так?

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

Речь о том, где инструментарий применим.

Кэр>>Еще раз — для стандартных задач писать regex не имеет смысла.
AVK>Кто такие стандартные задачи? Валидация емейла — стандартная задача?

Да.

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

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

Влад, ты с темы не спрыгивай. Только что ты утверждал, что HTML невозможно парсить regex'ами. Я тебе привел работающий пример, который хорошо справляется с этой задачей. Более того через него написан компилятор Asp.NET шаблонов.

Когда мне потребуется что-то специализированное — то я и поищу что-то специализированное. А пока мне и упомянутое решение пригодилось в практике всего пару раз.

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

ВВ>Грамматика как грамматика,

Агащазблин. Даже грамматика хмл-элемента (которая далеко не тоже самое, что грамматика ХМЛ-я) выглядит примерно вот так:

XMLElement  ::=
        XMLEmptyElement  |
        XMLElementStart  XMLContent  XMLElementEnd

XMLEmptyElement  ::=
        <  XMLQualifiedNameOrExpression  [  XMLAttribute+  ]  [  XMLWhitepace  ]  /  >

XMLElementStart  ::=
        <  XMLQualifiedNameOrExpression  [  XMLAttribute+  ]  [  XMLWhitespace  ]  >

XMLElementEnd  ::=
        <  /  >  |
        <  /  XMLQualifiedName  [  XMLWhitespace  ]  >

XMLContent  ::=
        [  XMLCharacterData  ]  [  XMLNestedContent  [  XMLCharacterData  ]  ]+

XMLCharacterData  ::=
        < Any XMLCharacterDataString that does not contain the string "]]>" >

XMLCharacterDataString  ::=
        < Any Unicode character except < or & >+

XMLNestedContent  ::=
        XMLElement  |
        XMLReference  |
        XMLCDATASection  |
        XMLProcessingInstruction  |
        XMLComment  |
        XMLEmbeddedExpression

XMLAttribute  ::=
        XMLWhitespace  XMLAttributeName  [  XMLWhitespace  ]  =  [  XMLWhitespace  ]  XMLAttributeValue  |
        XMLWhitespace  XMLEmbeddedExpression

XMLAttributeName  ::=
        XMLQualifiedNameOrExpression  |
        XMLNamespaceAttributeName

XMLAttributeValue  ::=
        DoubleQuoteCharacter  [  XMLAttributeDoubleQuoteValueCharacter+  ]  DoubleQuoteCharacter  |
        SingleQuoteCharacter  [  XMLAttributeSingleQuoteValueCharacter+  ]  SingleQuoteCharacter  |
        XMLEmbeddedExpression

XMLAttributeDoubleQuoteValueCharacter  ::=
        < Any XMLCharacter except <, &, or DoubleQuoteCharacter >  |
        XMLReference

XMLAttributeSingleQuoteValueCharacter ::=
        < Any XMLCharacter except <, &, or SingleQuoteCharacter >  |
        XMLReference

XMLReference  ::=  XMLEntityReference  |  XMLCharacterReference

XMLEntityReference  ::=
        &  XMLEntityName  ;

XMLEntityName  ::=  lt  |  gt  |  amp  |  apos  |  quot

XMLCharacterReference  ::=
        &  #  XMLNumericCharacter+  ;  |
        &  #  x  XMLHexNumericCharacter+  ;

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

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

VD>Ошибешься, это PEG. Он описывает парсер, а не грамматику языка.
VD>Но на EBNF (расширенный BNF) — это действительно похоже. Разница в трех вещах:

Спасибо, выглядит интересно.

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

Ошибся, там о другом речь шла.

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

Меня пседво код устроит. Мне принцип понять интересно.

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

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

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

Квалидентов у нас нет и быть не может, ибо нет пространств имен, о чем заявлялось изначально.
ХМЛ референс убираем по тем же причинам
Поддержку двойных и одинарных кавычек можно и оставить, хотя половина людей использующих ХМЛ даже не знает, что в нем можно одинарные кавычки использовать.

Что там осталось? Не так уж и много.
Причем речь, повторюсь, идет о "формате для конфигов" по сути, позволяющим хранить иерархические данные. Так что я правда не вижу ничего невозможного.

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

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

Кэр>Влад, ты с темы не спрыгивай. Только что ты утверждал, что HTML невозможно парсить regex'ами.

И продолжаю это делать.

Кэр>Я тебе привел работающий пример, который хорошо справляется с этой задачей.

Ты привел пример какого-то левоего класса на который даже документации нет, который никакого отношения к регулярным выражениям не имеет.

Кэр>Более того через него написан компилятор Asp.NET шаблонов.

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

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

Нет проблем. Только не называй его регулярными выражениями.

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

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

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

DM>Ващета никто не мешает в PEG разбирать не последовательность символов, а последовательность токенов от лексера. Я так делал как раз.
Единственный смысл разбирать лексемы PEGом — композиция грамматик.

Parr[ANTLR] — Grimm[Rats!]

Furthermore, once you combine both lexical and hierarchical syntax, i.e., rely on scannerless parsing, you can do strictly more. Martin Hirzel and I have combined the complete Java and C languages into a new language (called Jeannie) to substantially simplify Jave Native Interface programming. The syntactic composition of the existing grammars for Java and C was trivial thanks in part to scannerless parsing. Several papers by Eelco Visser make a similar case for other language extensions, only they are building on a scannerless GLR parser generator

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

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

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

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

Кстати, вот эта строка:
VD>

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

неверна, так как оператор "/" просто не выполнит второе вхождение в случае обранужения \". Чтобы правило разбирало то что требуется нужно поменять подправила местами:

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

Тогда будет производиться попытка распознать последовательность \" и если это не она, то просто \.

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

Кэр>Вы меня тут так процитировали, что я даже растерялся

Смысл оставлять длинные простыни цитат? Ты уже сам не помнишь о чем писал?

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

Все ходы записаны:

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

Кэр>Почему?

Дело не в моей цитате, а в том, что ты как то странно задаешь вопросы. Забываешь русский язык?

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

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

Кэр> Я просто прагматично подхожу к процессу.

На мой вкус — черезмерно прагматично.

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

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

Тысчитаешь, что я преувеличиваю?

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

Кэр>Именно поэтому я и спрашивал у тех, кто разобрался для решения каких задач нужна технология

Тебе ответили. Ответ тебе не понравился

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

Кэр>Мне ответили, что PEG — нужны там, где нужны regex

В том числе.

Кэр>1. Проверка шаблона (различные верификаторы). Для большинства стандартных случаев уже просто есть regex, которые работают.
Кэр>2. Эмпирическое выделение/разделение кусков текста. Выкусить конкретное значение аттрибута, или имя класса, или еще что-то в таком духе. Или порезать тот же SQL на блоки команд. Полная грамматика языка тут не нужна. Хватает эвристик на пару с regex'ами.
Кэр>3. Полноценный разбор текста, построение AST, анализ структур и прочее. Необходима грамматика — с ней должно быть удобно работать. Этот пункт важен для компилятора Немерле, важен для РеШарпера, важен для тех несчастных душ, которые на волне хайпа будут пытаться свои конфиги записывать как DSL. Совершенно неважен для большинства реальных задач инженера.

Кэр>Что я пропустил? Что тут не так?

4. Разбор форматов входных данных, которые должны быть человекочитаемы. Не xmlем единым, короче.
5. Текстовые DSL всех мастей
6. Средства абстрагирования от сторонних реализаций. Например промежуточный SQL, транслируемый в SQL конкретного сервера.
7. Средства разбора сложных структур данных. Например парсеры expression tree в провайдерах линка.
8. Ситуациии, когда текстовое описание намного короче графического или xml-образного. Монстриков с декларативным заданием логических выражений в виде дерева наверное многие видели. Проще ведь написать <filter expr="Age > 3 & Weight < 5"/>, чем такое:

<filter>
  <expr>
    <and>
      <greater>
        <property name="Age"/>
        <const value="3"/>
      </greater>
      <less>
        <property name="Weight"/>
        <const value="5"/>
      </less>
    </and>
  </expr>
</filter>

9. Всевозможный мелкий девелоперский инструментарий. Например condition breakpoint, окошко watch, окошко команд в студии\
10. Ситуации обработки слегка отмаркапленого текста. См. для примера форматтер рсдн. Оно конечно сейчас большей частью на регексах, но именно от этого проистекает большинство его проблем.

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

Кэр>>>Еще раз — для стандартных задач писать regex не имеет смысла.
AVK>>Кто такие стандартные задачи? Валидация емейла — стандартная задача?

Кэр>Да.

А ведь пишут.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>Мне не хочется.

Это я давно уже понял.

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

VD>Я не очень представляю себе как будет на практике выглядеть смесь из деревьев выражений и кодогенерации на Т4

Смесь то зачем? Смесь не нужна.

VD>, но раз речь зашла об деревьях выражений, то это уже по определению будет рантайм-решением (хотя бы частично)

Во-первых при первом запуске результат компиляции можно прокешировать, во-вторых никто не мешает тебе выдернуть ET из IL кода в design-time, IL для них генерируется тривиальный.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>Далее если подумать, то становится очевидным, что если бы вопрос создания собственного формата не привносил бы больших сложностей, т.е. если бы формат можно было бы быстренько описать с помощью PEG (с которым, предположим, человек хорошо знаком) и легко интегрировать в свое приложение, то многие предпочли бы специализированные форматы вместо ХМЛ-я или ини-файлов.

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

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

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

VD>Нет.

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

VD>Я ее видел. Но вот описывать ее мне тяжело.

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

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

VD>Не было не только парсеров, но и самого ХМЛ-я. Уверен, что о ХМЛ-е ты узнал примерно в то же время когда узнал о дотнете.

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

VD>Сольно. Раз эдак в 10. Его без подготовки мало кто быстро написать может.

То есть эпитет "умеючи" ты расшифровал как "без подготовки"? Или просто прочитал по диагонали?

VD>Вот ты лично хотя бы один ХМЛ-парсер написал?

Совсем простенький — было дело. Как раз на дельфях. Но больше для баловства, в продакшн код не пошел.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

Проблема в выделенном.

ЗЫ

Когда-то давно я изучал экономику по учебнику одного западного орла. Там был один очень любопытыный пример. Касался он пошлин. Точно уже я его не вспомню, но суть была примерно такая... Есть страна которая держит высокие ввозные пошлины на нефть. У этой страны есть много зерна. И тут приходит орел и говорит — "Я нашел охренительный способ получения дизельного топлива из зерна! Очень дешевый и эффективный!". Его спрашивают — "Какой!". Он отвечает — "Нам нужно продавать зерно зарубеж и на эти деньги покупать нефть или диз.топливо.".

Твое сообщение почему-то напомни об этом примере.

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

ВВ>Грамматика у Немерле, конечно же, более сложная, однако я действительно не понимаю, как это может помешать в данном случае.

Да ладно. Неужели правда не понимаешь?

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

Теперь представь что может произойти. Приносит им Андрей казалось бы безобидную тулзу-генератор парсеров. Народ на ней офигачивает средней сложнсоти парсер оформляя обработку семантики (как и раньше) на шарпе.
Но народ ведь по определению ленив. Увидев, что в этой тулзе создаются классы он может сказать себе — "О! А зачем мне обработку семантики куда-то выносить? Дай как я мальца сэкономлю и реализую ее прямо здесь". Пробуют... и к их немалому удивлению все получается не хуже чем на шарпе. Пока пробуют они пару раз залезают в документацию и/или статьи и обнаруживают, что у этой тулзы есть фишки которые очень пригодились бы в шарпе. Далее следует еще более крамольная мысль — а не попробовать ли част логики оформить на этом диковинном языке? Пробуют... и, о чудо, получается лучше чем на шрпе! Дальше они начинают преставать к Андрею, мешая ему работать, с вопросами вроде "А чё мы вообще все на этом языке не пишем?". Это приводит к полной остановке работы флэймам и как развалу к полному развалу всего рабочего процесса.

ВВ>Собственно, на Немерле придется описывать лишь семантические действия, и грамматика там весьма ограниченная.

Сематические действия тоже можно описать абстрактными функциями и реализовать на шарпе.

ВВ>Вообще на Немерле можно писать "как на C#" — и разница будет минимальной.

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

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

AVK>В семантических действиях можно использовать любые возможности Немерле. Со всеми вытекающими.

Объяви их модификатором abstract и нет проблем.

ВВ>>Ты боишься того, что кто-то начнет в таком "проекте парсера" использовать Немерле "на полную катушку"?

AVK>Боюсь.

И очень правильно делаешь! Так оно и будет.

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

VD>Теперь представь что может произойти. Приносит им Андрей казалось бы безобидную тулзу-генератор парсеров. Народ на ней офигачивает средней сложнсоти парсер оформляя обработку семантики (как и раньше) на шарпе.
VD>Но народ ведь по определению ленив. Увидев, что в этой тулзе создаются классы он может сказать себе — "О! А зачем мне обработку семантики куда-то выносить? Дай как я мальца сэкономлю и реализую ее прямо здесь". Пробуют... и к их немалому удивлению все получается не хуже чем на шарпе. Пока пробуют они пару раз залезают в документацию и/или статьи и обнаруживают, что у этой тулзы есть фишки которые очень пригодились бы в шарпе. Далее следует еще более крамольная мысль — а не попробовать ли част логики оформить на этом диковинном языке? Пробуют... и, о чудо, получается лучше чем на шрпе! Дальше они начинают преставать к Андрею, мешая ему работать, с вопросами вроде "А чё мы вообще все на этом языке не пишем?". Это приводит к полной остановке работы флэймам и как развалу к полному развалу всего рабочего процесса.

Пороть их надо за это, пороть

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

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

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

А если из этой серии?

AVK>то применение подобных вещей самоубийственно.

Вот незадача, компилятор немерла на нем же и написан. И этому проекту уже 5 лет. Значит можно выжить после самоубийства?

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

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

Да технически — это не проблема. Можно написать один простенький макрос который обеспечит такой контроль. Я в проекте компилятора сделал макрос который контролирует, что все переменные типа Location должны быть изменяемыми. Это же плевое дело. Вот только люди же не идиоты. Они очень быстро начнут задавать вопросы вроде "Зачем мы ограничиваем себя в еде?".

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

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

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

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

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

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

>>>> С целью сбора статистики. Интересно готов ли народ использовать на
>>>> практике подобные вещи. Регекспы, при всей их убогости, используются по

MZ>>>Это типа DSL-и строить ?

VD>>И они в том числе. PEG или EBNF помогли бы упростить решение массы задач связанных с разбором строк. В прочем, очень часто эти задачи (не осмысленно) являются частью пути программиста к DSL-ям.

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

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

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

ВВ>ХМЛ референс убираем по тем же причинам

Это по каким же? А как мы в нашем ХМЛ-е запишем "<" ?

ВВ>Поддержку двойных и одинарных кавычек можно и оставить, хотя половина людей использующих ХМЛ даже не знает, что в нем можно одинарные кавычки использовать.

Они об этом узнают как только им нужно вписать в значение атрибута ту самую кавычку. Ну, или узнают о существаонии референсов.

ВВ>Что там осталось? Не так уж и много.

Грамматика на 3 экрана.

ВВ>Причем речь, повторюсь, идет о "формате для конфигов" по сути, позволяющим хранить иерархические данные. Так что я правда не вижу ничего невозможного.

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

!

ВВ>Два дня где-то я писал парсер JSON-а по спекам, причем врукопашную, с рукопашной же токенизацией.

О! Значит не 2 часа, а два дня? А ведь джейсон то по проще будет.

Кстати, а почему джейсон не используется для представления даных в шарпе? Ведь по определению АВК (которое ты тут защищаешь) должен! Формат простой, парсится легко. При этом он еще более компактный и гибкий. Но вот используют его исключительно для передачи данных броузерам, так как там есть АПИ для их чтения (ЯваСкрипт).

ВВ>На третий день сделал генератор и сериализатор. Сериализатор вяло допиливался и фиксился еще недели две. Все остальное работало с минимальными фиксами после базовых тестов.

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

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

VD>>Я не очень представляю себе как будет на практике выглядеть смесь из деревьев выражений и кодогенерации на Т4

AVK>Смесь то зачем? Смесь не нужна.

Это твои слова:
AVK>>Зачем рантайм? Нужен кодогенератор банальный. Например в виде шаблона Т4.
...
AVK>Можно и взаимодействие сделать. При помощи expression tree. Не так красиво, как со спецсинтаксисом, но вполне юзабельно. Irony видел?

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

VD>>, но раз речь зашла об деревьях выражений, то это уже по определению будет рантайм-решением (хотя бы частично)

AVK>Во-первых при первом запуске результат компиляции можно прокешировать,

Да хоть в пятых. Я про кэширование сразу сказал. Но кэширование не делате из рантайм-решения компайлтайм-решение. Все ошибки ведь будут валиться в рантайме, и время на компиляцию тоже в рантайме будет тратиться.

AVK>во-вторых никто не мешает тебе выдернуть ET из IL кода в design-time, IL для них генерируется тривиальный.

Чё? Это еще после компиляции нужно будте декомпилировать сборку и возиться с ИЛ-ом? Не — это точно без меня. Сам лучше попробуй. Я и так офигиваю с того как ИТ с ИЛ-ом возится в своем БЛТулките.

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

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

!
ВВ>>Два дня где-то я писал парсер JSON-а по спекам, причем врукопашную, с рукопашной же токенизацией.
VD>О! Значит не 2 часа, а два дня? А ведь джейсон то по проще будет.

У тебя какая-то путаница с цифрами последнее время

Речь с самого начала была про "пару дней". Про пару часов никто не говорил.
В JSON-е кстати нужно разбирать те же флоатов по стандарту. Если врукопашную — то это не так просто. А в нашем сабсете ХМЛ-я таких задач нет.

VD>Кстати, а почему джейсон не используется для представления даных в шарпе? Ведь по определению АВК (которое ты тут защищаешь) должен! Формат простой, парсится легко. При этом он еще более компактный и гибкий. Но вот используют его исключительно для передачи данных броузерам, так как там есть АПИ для их чтения (ЯваСкрипт).
ВВ>>На третий день сделал генератор и сериализатор. Сериализатор вяло допиливался и фиксился еще недели две. Все остальное работало с минимальными фиксами после базовых тестов.
VD>Ага, значит за два дня он так и не заработал? Так ты чьи слова то пытался подтвердить?

Работал. Но "не для всех случаев". Ну так это сериализатор. Парсер работал.

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

AVK>Дело не в моей цитате, а в том, что ты как то странно задаешь вопросы. Забываешь русский язык?

Пусть будет так.

AVK>Одно но — молоток новый совсем не для всех. Не буду говорить за других, но лично я никогда не бросаюсь рекламировать что то новое, в чем я сам не разобрался.

Я всего лишь ответил общей фразой на вашу общую фразу.

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

Пока конкретика не началась ответить на эту фразу невозможно. Список вы, кстати, внизу очень неплохо продолжили внизу. Сейчас по нему продолжим.

AVK>Тебе ответили. Ответ тебе не понравился

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

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

AVK>4. Разбор форматов входных данных, которые должны быть человекочитаемы. Не xmlем единым, короче.
AVK>5. Текстовые DSL всех мастей

Пункты 4/5 как-то отличаются? DSL, кстати, очень ограничен в применении. Разработать DSL для крутого фреймворка, типа замены Asp.NET MVC — это правильно. Разработать DSL, чтобы прочитать конфиг или обменяться данными между серверами — это почти всегда неправильно.

AVK>6. Средства абстрагирования от сторонних реализаций. Например промежуточный SQL, транслируемый в SQL конкретного сервера.

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

AVK>7. Средства разбора сложных структур данных. Например парсеры expression tree в провайдерах линка.

Как здесь PEG помогает? Expression tree разве не будет представлено там в объектном виде? Тут паттерн-матчинг более в тему, нет?

AVK>8. Ситуациии, когда текстовое описание намного короче графического или xml-образного. Монстриков с декларативным заданием логических выражений в виде дерева наверное многие видели. Проще ведь написать <filter expr="Age > 3 & Weight < 5"/>, чем такое:
AVK>

AVK><filter>
AVK>  <expr>
AVK>    <and>
AVK>      <greater>
AVK>        <property name="Age"/>
AVK>        <const value="3"/>
AVK>      </greater>
AVK>      <less>
AVK>        <property name="Weight"/>
AVK>        <const value="5"/>
AVK>      </less>
AVK>    </and>
AVK>  </expr>
AVK></filter>
AVK>

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

AVK>9. Всевозможный мелкий девелоперский инструментарий. Например condition breakpoint, окошко watch, окошко команд в студии\

Зачем изобретать велосипед? Берем какой-нибудь скриптовый язык и вперед.

AVK>10. Ситуации обработки слегка отмаркапленого текста. См. для примера форматтер рсдн. Оно конечно сейчас большей частью на регексах, но именно от этого проистекает большинство его проблем.

Хм, вот это реально интересно.

AVK>Это только то, что навскидку вспомнилось. Список далеко не полный.
AVK>И да, забавно, что ты не считаешь компилятор Немерле и Решарпер реальными задачами инженера.

Я этого не говорил. Я говорил, что большинство инженеров не решают эти задачи.

Кэр>>Да.
AVK>А ведь пишут.

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

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

AVK>Во-первых, придумывание хорошего формата тоже не всегда тривиально и требует времени и усилий.

Не всегда. Я за все случае и не говорю. Частенько тот же ХМЛ является отличным форматом.
Но иногда бывает, что формат или уже есть, или очевиден для программиста. И тут останавливающим фактором становится исключительно отсутствие средств шаговой доступности. Ведь даже на то чтобы взяться за создание внешнего ДСЛ-я уже нужно не мало мужества и гибкости ума. А вместе с рутиной которая возникает в следствии того что нужно прикручивать разные генераторы парсеров и т.п. такие мысли умирают раньше чем успевают закрепиться в голове.

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

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

AVK>Угу. Потому что ты с ней не разобрался.

Есть вещи которые становятся понятны в процессе того как ты на них смотришь. Вот PEG, например, или ХМЛ. А схема не из этих вещей. С ней нужно долго и нудно разбираться.

AVK>При этом на моей памяти народ легко со схемами разбирался, буде возникала необъезжаемая потребность. Чего, увы, не скажешь про инструментарий типа яка или коко.

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

VD>>Не было не только парсеров, но и самого ХМЛ-я. Уверен, что о ХМЛ-е ты узнал примерно в то же время когда узнал о дотнете.

AVK>Ну, как обычно, твои предположения — пальцем в небо.

Как обычно ты находишь все пробелмы во мне и переводишь стрелки. Меж тем я говорю то что есть. В 1996 ХМЛ никто не знал и парсеров для него еще не было. Его еще популяризировали года два. А к тому времени уже были и дельфи 3 и КОМ и даже дотнет.

AVK>То есть эпитет "умеючи" ты расшифровал как "без подготовки"? Или просто прочитал по диагонали?

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

AVK>Совсем простенький — было дело. Как раз на дельфях. Но больше для баловства, в продакшн код не пошел.

Во-во. Баловства за день конечно можно сделать. Но мы то с тобой знаем чем прототип написанный для баловства отличается от того чем в последствии можно будет пользоваться. Не так ли?

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

VD>А если из этой серии?

Тогда можно попробовать.

VD>Вот незадача, компилятор немерла на нем же и написан.

Этого мало. Вон IT у себя линк применял из BLT довольно долго. А как янус стали на него перетаскивать — первое время баги сыпались вагонами.

VD> И этому проекту уже 5 лет. Значит можно выжить после самоубийства?

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

VD>И сотни пользователей наверно еще нет. Более того, не исключено что и баги в нем есть. Но не уж то что-то изменится в твоем мнении, когда появится эта сотня?

Изменится.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

Мой парсер слова "смесь" в цитате не обнаружил.

VD>А то я уже ничего не понимаю. Начал с того что натайм-решение не нужно, а нужен Т4, а закончил как раз таки рантайм-решением и без Т4.

Про Т4 можешь забыть, не суть.

AVK>>во-вторых никто не мешает тебе выдернуть ET из IL кода в design-time, IL для них генерируется тривиальный.

VD>Чё? Это еще после компиляции нужно будте декомпилировать сборку и возиться с ИЛ-ом?

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

VD> Не — это точно без меня. Сам лучше попробуй.

Парадокс Блада?

VD> Я и так офигиваю с того как ИТ с ИЛ-ом возится в своем БЛТулките.

И зря офигеваешь. Ничего сложного там нет. А как перепишет генерацию на ET, так совсем все просто станет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>Кстати, а почему джейсон не используется для представления даных в шарпе?

Потому что не совпадает с генеральной линией партии.

VD> Ведь по определению АВК (которое ты тут защищаешь) должен! Формат простой, парсится легко. При этом он еще более компактный и гибкий. Но вот используют его исключительно для передачи данных броузерам, так как там есть АПИ для их чтения (ЯваСкрипт).

Для шарпа готовых парсеров JSON не один.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

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

Шутки шутками, но на самом деле вопрос конечно же в основном политический.

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

Более того на практике такой контроль и не нужен вовсе. Это все опасения тех кто язык вообще не пробовал.

Ну, а бардак есть бордак. Как говорил один мой знакомый — "Бардак автоматизировать нельзя.".

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

Кэр>Я всего лишь ответил общей фразой на вашу общую фразу.

А сказать чего хотел? Ну, абстрагируясь от моих общих фраз?

Кэр>Пока конкретика не началась ответить на эту фразу невозможно.

Т.е. это была реплика в никуда?

Кэр>Странно, что вы там усмотрели поучение жизни

Неверный вывод. Я такого не усмотрел.

Кэр>Но да, для безоговорочного авторитета десятилетия программирования маловато. Иногда возраст действительно приходит один.

Да дело не в возрасте. Маловато на поверку выходит всего. Нет авторитетов в принципе.

Кэр>Пункты 4/5 как-то отличаются?

Да. DSL описывает, как правило, логику в той или иной форме, а не входные данные для обработки.

Кэр> DSL, кстати, очень ограничен в применении.

DSL как технология — практически не ограничена, вопрос лишь в соотношении затрат и бенефитов. Конкретный DSL — безусловно ограничен, ради этого его и делают.

Кэр> Разработать DSL для крутого фреймворка, типа замены Asp.NET MVC — это правильно. Разработать DSL, чтобы прочитать конфиг или обменяться данными между серверами — это почти всегда неправильно.

КО?

Кэр>Интересно. Вот только стоит ли игра свеч в данном случае?

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

Кэр> Обычно в таких случаях бывает проще разработать отдельно слой базы данных для одной базы и отдельно для другой.

Я тебя умоляю.

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

Это они у безруких только зависают, ИМХО.

AVK>>7. Средства разбора сложных структур данных. Например парсеры expression tree в провайдерах линка.

Кэр>Как здесь PEG помогает?

Как PEG помогает в задаче парсинга?

Кэр> Expression tree разве не будет представлено там в объектном виде?

А толку то? Объектный вид там конечно есть, да не тот. А дальше все та же задача парсинга — распознать паттерны во входном потоке, и сформировать поток выходной.

Кэр> Тут паттерн-матчинг более в тему, нет?

Паттерн-матчинг это хорошо, но PEG более высокоуровневое средство.

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

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

AVK>>9. Всевозможный мелкий девелоперский инструментарий. Например condition breakpoint, окошко watch, окошко команд в студии\

Кэр>Зачем изобретать велосипед? Берем какой-нибудь скриптовый язык и вперед.

И еще один пример из пушки по воробьям.

AVK>>Это только то, что навскидку вспомнилось. Список далеко не полный.
AVK>>И да, забавно, что ты не считаешь компилятор Немерле и Решарпер реальными задачами инженера.

Кэр>Я этого не говорил.

Это прямо следует из твоей фразы.

Кэр> Я говорил, что большинство инженеров не решают эти задачи.

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

Кэр>

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

А в дурной ли практике дело?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>>Кстати, а почему джейсон не используется для представления даных в шарпе?

AVK>Потому что не совпадает с генеральной линией партии.

Во как? Значит твои рассуждения все же не верны, и дело вовсе не в простоте формата, а в некой линии партии?

С этим я согласен. Те же S-выражения Лиспа на 40 лет старше, в пять раз удобнее и в 10 проще, но я что-то не видел чтобы их кто-то применял для хранения и передачи данных в яве или дотнете.

VD>> Ведь по определению АВК (которое ты тут защищаешь) должен! Формат простой, парсится легко. При этом он еще более компактный и гибкий. Но вот используют его исключительно для передачи данных броузерам, так как там есть АПИ для их чтения (ЯваСкрипт).

AVK>Для шарпа готовых парсеров JSON не один.

А это уже не важно. Главное, что не используют. А ХМЛ используют. Что и требовалось доказать.

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

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

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

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

Кэр>>Влад, ты с темы не спрыгивай. Только что ты утверждал, что HTML невозможно парсить regex'ами.
VD>И продолжаю это делать.

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

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

Почему не имеет? Там внутри regex заоптимизорован, но он остается regex'ом.

Кэр>>Более того через него написан компилятор Asp.NET шаблонов.
VD>Тебе, кстати, уже заметил, что компилятор шаблонов Asp.NET работает весьма криво. Так что не ясно что твои слова могут доказывать.

Это то, что серверный тэг нельзя так закомментарить — это весьма криво?

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

VD>Не всегда. Я за все случае и не говорю. Частенько тот же ХМЛ является отличным форматом.

Вот поэтому все его и используют.

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

На моей практике такого ни разу не было. Ну чтобы отсутствие парсера остановило. А так — чего только в природе не бывает.

VD>Несомненно. Но все же делает решение реалистичным.

Не настолько кардинально. Самопальные конфиги, о которых ты выше говорил, легко укладываются в LL(1), и CoCo для них хватает выше крыши.

VD>Есть вещи которые становятся понятны в процессе того как ты на них смотришь. Вот PEG, например, или ХМЛ. А схема не из этих вещей. С ней нужно долго и нудно разбираться.

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

AVK>>Ну, как обычно, твои предположения — пальцем в небо.

VD>Как обычно ты находишь все пробелмы во мне

Классная ржака. Обвинил меня, а на ответ, что с обвинениями не угадал начал обвинять меня в том, что сам делаешь.

VD> и переводишь стрелки. Меж тем я говорю то что есть. В 1996 ХМЛ никто не знал

Я знал. И если ты еще раз будешь обвинять меня во вранье, я просто прекращу разговор.

VD>Ели ты пишешь по парсеру во время завтрака, то конечно ты прав. Вот только так ли это? Я вот не так крут, чтобы за часы (за день, что уж там часы?) написать работающий ХМЛ-парсер.

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

VD>Во-во. Баловства за день конечно можно сделать.

При чем тут это? Мои тогдашние умения к обсуждению отношения не имеют. Я сейчас я бы без проблем написал.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>>А если из этой серии?
AVK>Тогда можно попробовать.

Обана! Это огромный прогресс!

VD>>Вот незадача, компилятор немерла на нем же и написан.

AVK>Этого мало. Вон IT у себя линк применял из BLT довольно долго. А как янус стали на него перетаскивать — первое время баги сыпались вагонами.

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

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

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

VD>> И этому проекту уже 5 лет. Значит можно выжить после самоубийства?

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

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

VD>>И сотни пользователей наверно еще нет. Более того, не исключено что и баги в нем есть. Но не уж то что-то изменится в твоем мнении, когда появится эта сотня?

AVK>Изменится.

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

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

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

Мы работаем в этом направлении

Я жду твоего ответа с псевдо-кодом на C# ниже по ветке. Причем мне действительно будет интересно его увидеть.

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

VD>>А то я уже ничего не понимаю. Начал с того что натайм-решение не нужно, а нужен Т4, а закончил как раз таки рантайм-решением и без Т4.

AVK>Про Т4 можешь забыть, не суть.

То есть ты таки отказываешься от своего исходного предложения и соглашаешься со мной в том, что для шарпа проще динамическое решение сделать (на тех же экспрешон трях, к примеру)?

AVK>Это совсем несложно. В CCI есть даже всякие обертки, с которыми задача превращается в просто тривиальную.

Ага. Опять преимущественно языком?

VD>> Не — это точно без меня. Сам лучше попробуй.

AVK>Парадокс Блада?

Какой парадокс? Лично я бинарных файлах копаться не намерен. Ты предложил, ты и пробуй.

VD>> Я и так офигиваю с того как ИТ с ИЛ-ом возится в своем БЛТулките.

AVK>И зря офигеваешь. Ничего сложного там нет. А как перепишет генерацию на ET, так совсем все просто станет.

Ага. Ничего. ИТ так и сказал — "Если бы я знал во что это выльется, то не взялся бы.".

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

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

Ты меньше делай предположений, высосанных из пальца.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>Во как? Значит твои рассуждения все же не верны

Логическую цепочку не продемонстрируешь?

VD>, и дело вовсе не в простоте формата, а в некой линии партии?

В случае отсутствия парсера в фреймворке — безусловно многое определяется линией партии. Но это никак тому что по ссылке не противоречит.

VD>А это уже не важно.

То есть если факты не соответствую теории, тем хуже для фактов?

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>Вот только те, кто боятся использовать Немерле, об этих возможностях не знают.

Теперь знают!

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

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

ВВ>Ибо страх использовать приводит к отсутствию интереса, что вполне закономерно.

Здесь причина и следствие противоположенные.

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

Это из серии статей о том как не бояться спать без света и ходить одному в лес. Страх — это животное чувство. Его аналитическими рассуждениями не убрать.

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

Кэр>>>Влад, ты с темы не спрыгивай. Только что ты утверждал, что HTML невозможно парсить regex'ами.
VD>>И продолжаю это делать.

Кэр>Ну и с какой целью?

Да тебе уже раз 5 обяснили все. И не я один. Если что-то парсит ХТМЛ/ХМЛ, то это принципиально не регулярные выражения, так как подерживает рекурсию. Так же тебе обяснили, что то что используется в АСП.НЭТ не разбирает ХТМЛ корректно, а всего лишь находит те самые парттерны, которые при некоторых условиях распознают не то что нужно. Но ты по шестому разу повторяешь одни и те же заблуждения.

Кэр>Особенно мне интересно, как собираетесь с помощью правильной грамматики разбирать поломанный HTML документ, как это обычно бывает. Вам все равно придется ограничиваться неполной грамматикой языка и эвристиками.

Для разбора поломанных файлов есть известные техники восстановления после обнаружения ошибок. Например, если обнаруживается ошибка в выражении, то в си-подобнх языках обычно пропускают поток до тех пор пока не втретят ";". В ХМЛ-е в случае не закрытой ковычки искать ближайшие "<" или ">". Но для того же АСП этого не надо, так как битый файл нет нужны обрабатывать. Там просто будет выдана ошибка.

Кэр>Почему не имеет? Там внутри regex заоптимизорован, но он остается regex'ом.

Дык он или не разбирает ХТМЛ, а ищет некую подстроку, или он содержит вручную написанную логику.

В ХТМЛ-е есть вложенные теги. Это пример рекурсивной грамматики. Ее можно разобрать только парсером поддерживающим рекурсию правил. Это азы парсинга.

Кэр>>>Более того через него написан компилятор Asp.NET шаблонов.
VD>>Тебе, кстати, уже заметил, что компилятор шаблонов Asp.NET работает весьма криво. Так что не ясно что твои слова могут доказывать.

Кэр>Это то, что серверный тэг нельзя так закомментарить — это весьма криво?

А что — это хорошо? Код то корректный. Был бы полноценный парсер, он бы это дело спокойно съел.

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

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

Я предположения "высосал" из нашего обсуждения. А раз ты все знаешь, то чего ж тогда прикидываешься? Тут Влад оказывается тебе -disableMacros сделать предлагал. Получается, дело вовсе не в "страшных макросах". А здесь уже и методом исключения никаких причин, кроме религиозных, не остается.

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

ВВ>>Я так понял, АВК не знал даже, что для синтаксических макросов отдельный проект нужен.
VD>Он то как раз все знал. И про то что все макрами можно проконтролирвоать тоже знал. Я ему даже предлагал прикрутить спец.ключик к компилятору запрещающий использование любых макросов окромя тех что из стандартной библиотеки идут (или даже по выбору).

Тогда я вообще его не понимаю.

ВВ>>Ибо страх использовать приводит к отсутствию интереса, что вполне закономерно.
VD>Здесь причина и следствие противоположенные.

Возможно.

ВВ>>Вот, кстати, неплохая тема для статьи. Как не боятся использовать Немерле и как проконтроливать его использование. Мне самому было бы очень интересно почитать такое.
VD>Это из серии статей о том как не бояться спать без света и ходить одному в лес. Страх — это животное чувство. Его аналитическими рассуждениями не убрать.

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

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

Кэр>>Я всего лишь ответил общей фразой на вашу общую фразу.
AVK>А сказать чего хотел? Ну, абстрагируясь от моих общих фраз?

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

Кэр>>Пока конкретика не началась ответить на эту фразу невозможно.
AVK>Т.е. это была реплика в никуда?

Нет это была реплика про то, что я хотел получить список реальных задач и я их получил.

Кэр>>Странно, что вы там усмотрели поучение жизни
AVK>Неверный вывод. Я такого не усмотрел.

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

AVK>Да дело не в возрасте. Маловато на поверку выходит всего. Нет авторитетов в принципе.

Тогда непонятно в каком контексте вы упоминали десятилетия опыта. Ладно запишем это на мое незнание русского языка. Мне не особо интересно педалить эту тему.

AVK>DSL как технология — практически не ограничена, вопрос лишь в соотношении затрат и бенефитов. Конкретный DSL — безусловно ограничен, ради этого его и делают.

КО?

Кэр>> Разработать DSL для крутого фреймворка, типа замены Asp.NET MVC — это правильно. Разработать DSL, чтобы прочитать конфиг или обменяться данными между серверами — это почти всегда неправильно.
AVK>КО?

Ага

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

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

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

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

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

Кэр>> Expression tree разве не будет представлено там в объектном виде?
AVK>А толку то? Объектный вид там конечно есть, да не тот. А дальше все та же задача парсинга — распознать паттерны во входном потоке, и сформировать поток выходной.

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

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

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

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

AVK>И еще один пример из пушки по воробьям.

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

AVK>Это прямо следует из твоей фразы.

У нас версии русских языков несовместимы. Мне даже интересно стало. Каким образом это прямо следует из моей фразы? Особенно в контексте других моих фраз про использование грамматики в РеШарпере в этой теме.

AVK>А большинство людей вообще не программируют. Ты считаешь себя хорошим программистом или одним и миллиона леммингов?

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

AVK>А в дурной ли практике дело?

А в чем еще? Есть обкатанное решение. Понять как оно работает перед использованием — надо. Изобретать что-то свое предварительно не поискав в интернете готовые решения — не надо.

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

VD>Да тебе уже раз 5 обяснили все. И не я один. Если что-то парсит ХТМЛ/ХМЛ, то это принципиально не регулярные выражения, так как подерживает рекурсию. Так же тебе обяснили, что то что используется в АСП.НЭТ не разбирает ХТМЛ корректно, а всего лишь находит те самые парттерны, которые при некоторых условиях распознают не то что нужно. Но ты по шестому разу повторяешь одни и те же заблуждения.

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

VD>Для разбора поломанных файлов есть известные техники восстановления после обнаружения ошибок. Например, если обнаруживается ошибка в выражении, то в си-подобнх языках обычно пропускают поток до тех пор пока не втретят ";". В ХМЛ-е в случае не закрытой ковычки искать ближайшие "<" или ">". Но для того же АСП этого не надо, так как битый файл нет нужны обрабатывать. Там просто будет выдана ошибка.

Почему? Может быть задача конкертного куска шаблона содержать именно "битый" HTML. Выдавать ошибку тут как раз не надо.

VD>А что — это хорошо? Код то корректный. Был бы полноценный парсер, он бы это дело спокойно съел.

Это не хорошо и не плохо. Это примерно вот так: ну и что

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

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

AVK>На моей практике такого ни разу не было. Ну чтобы отсутствие парсера остановило. А так — чего только в природе не бывает.

Это говорит исключительно о твоей практике. У других было.

AVK>Не настолько кардинально. Самопальные конфиги, о которых ты выше говорил, легко укладываются в LL(1), и CoCo для них хватает выше крыши.

Именно кардинально. Если бы проблем с подключением и использованием разных Кок не было, то многие бы решились на разработку своих форматов/дслей.

VD>>Есть вещи которые становятся понятны в процессе того как ты на них смотришь. Вот PEG, например, или ХМЛ. А схема не из этих вещей. С ней нужно долго и нудно разбираться.

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

ПЕГ можно обяснить за пять минут любому кто знаком с регулярными выражениями. Вот здесь я описал три основных отличия:
http://rsdn.ru/forum/philosophy/3864596.1.aspx

AVK>>>Ну, как обычно, твои предположения — пальцем в небо.

VD>>Как обычно ты находишь все пробелмы во мне

AVK>Классная ржака. Обвинил меня, а на ответ, что с обвинениями не угадал начал обвинять меня в том, что сам делаешь.

В чем я тебя обвинил? Я сказал, что твои слова не соответствую действительности хотя бы потому, что ХМЛ повинился через год после того как появился Дельфи. Так же я сказал, что в Дельфи 2 уже поддерживался КОМ и стало быть MSXML в нем можно было использовать сразу как он появился. А появился он в 1997 году. Рассказы о массовом применении только что вышедшего формата доверия тоже не вызывают.

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

AVK>Я знал. И если ты еще раз будешь обвинять меня во вранье, я просто прекращу разговор.

Не надо меня пугать. Разговор уже давно идет не о чем. Его давно пора прекратить.

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

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

Кэр>Мы работаем в этом направлении

Я жду твоего ответа с псевдо-кодом на C# ниже по ветке. Причем мне действительно будет интересно его увидеть.

Если тебе нужно просто найти подстроку <xxx> в некоторой строке, где xxx может быть полноценным ХМЛ-именем, а тег может содержать атрибуты, то код будет примерно таким:

var peg = Peg.CreatePattrn(@"
  xmlSpaces = ' ' / '\n' / '\r' / '\t';
  xmlIdent  = letter (letter / [0-9]+ / '-' / '_')+ xmlSpaces
  tagName   = nsPrefix ':' nsPrefix;
  tegOpen   = '<' xmlSpaces tagName (!'>' any)* '>'
  ", PegOptions.Compile);
var pegTegOpen = peg.GetGuleMatcher("tegOpen");
var source = "<z><Items>x</Items></z>";
var matchs = pegTegOpen.Matchs(source);

Console.WriteLine(matchs[tagName]);

Естественно это фантазии что называется без подготовки. Реальный дизайн может отличаться по многим причинам. Но общий смысл примерно такой.

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

LP>А формальные грамматики реализовывались бы не узкозаточенным инструментом, как вышеприведенные макросы, а на основе той самой семантики (например, путем задания семантического макроса с описанием грамматики). Это было бы фундаментальным решением, а не, пардон, костылем.
Браво! Именно так я и сделал. Синтаксис описания грамматик такой же как и синтаксис самого языка. И вообще все это единое целое. Благодаря этому описание грамматик может включать и операторы. Таким образом описание грамматики превращается непосредственно в программу. Вернее в два уровня программы (у меня называется уровни реализации). Первый уровень участвует в ходе разбора (т.е. имется возможность влиять на ветви разбора, и иногда обойтись без возвратов и т.п.), а второй выполняет функциональную часть при удачном (или не удачном) разборе. Т.е. создает классы и объекты для результата трансляции.

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

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

VD>>Во как? Значит твои рассуждения все же не верны

AVK>Логическую цепочку не продемонстрируешь?

Да ее, на мой взгляд, у тебя в рассуждениях и не было. Сначала "Прелесть XML прежде всего в его предельной простоте, по крайней мере базового слоя.". Потом когда более простой формат который по первому определению вроде как должен проходить появляется: "Потому что не совпадает с генеральной линией партии.".

Казалось бы если логика таки есть, то надо просто согласиться что тезис "что в использовании ХМЛ главное его простота" несостоятелен на том основании, что есть ряд не менее простых форматов которые не получили повсеместного использования. Но вместо этого идет отстаивание логически несостоятельной позиции.

Рассуждения становятся ситуационными. Для джейсон наш довод не рабортает, а для ХМЛ работает.

Меж тем мой тезис работает во всех случаях. Джейсон и S-выражения очень простые форматы, но используются они там где их использование очень просто (в соответствующих языках или при общении с ними). А ХМЛ везде просто потому, что это стандарт для которого созданы АПИ для всех живых языков.

VD>>, и дело вовсе не в простоте формата, а в некой линии партии?

AVK>В случае отсутствия парсера в фреймворке — безусловно многое определяется линией партии. Но это никак тому что по ссылке не противоречит.

Какая-то странная логика. Да и фрэймворк тут не причем. Бритву Окама помнишь? У нас есть два объяснения, сложное и простой. Сложно приплетает партии (которые есть не везде, кстати), простоту формата и еще что-то и есть простое — "Есть апи — используют, нет — не используют или используют редко". Конечно можно сказать что тотальное наличие ХМЛ-парсеров определяется стандартностью ХМЛ. Я с этим так же охотно соглашусь. Но уверен, что если не было бы этих самых АПИ, то стандартность не помогла бы. Вот в С++-стандарт входило много интересного. В новом стандарте кое что выбрасывают, так как в реальной жизни это кое-что не использовалось.

VD>>А это уже не важно.

AVK>То есть если факты не соответствую теории, тем хуже для фактов?

Ну, получается, что так. По крайней мере если послушать тебя.

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

ВВ>Тогда я вообще его не понимаю.

Да просто ты по-другому приоритеты ставишь, а он о реальны причинах говорить не очень хочет.

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

Ну, а почему не хочет — это уже отдельный разговор.

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

Тут недавно смотрел по дискавери "Разрушителей легенд" (кстати, просмотрел новую сери

), так вот там они проверяли миф, что мол если нагреть свинец до определенной температуры (что-то там выше 400 градусов), обмакнуть руку в воде, то можно засунуть ее в расплавленный свинец, вынуть и тебе ничего не будет. Миф оказался правдой. Более того он как-то там научно объясняется. Эти орлы проделали эксперимент на сосиске, который показал, что таки да, с сосиской все ОК. Тогда они решились засунуть свои руки в расплавленный свинец. Они точно знали, что ничего плохого не произойдет. Но видил бы ты их рожи когда они это делали! Вот за что люблю эту передачу!

Ну, а мораль такова. Смелость нельзя получить теоретическим путем.

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

O>Тут ты ошибаешься. Народ офигачивать не будет, скажет, что не знает че это такое и нафига нам оно надо.

Ага. Я ошибась. В прошлый раз я тут с Ziaw спорил. Он тоже говорил что я ошибаюсь... А сейчас вот он близок к релизу NRails (аналог Ruby on Rails)

.

Классный, кстати, фрэймворк получился!

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

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

Можно вопрос лично к тебе?
Давай представим что ты и есть тот самый народ. Надеясь, что с BNF или хотя бы с регулярными выражениями ты знаком? Тогда давай проведем один эксперимент.

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

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

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

VD>Можно вопрос лично к тебе?
Можно.

VD>Давай представим что ты и есть тот самый народ.
Окей, будем простым народом.

VD>Надеясь, что с BNF или хотя бы с регулярными выражениями ты знаком?
Что-такое BNF — без понятия. Про регулярные выражения что-то слышал краем уха, если надо — с грехом пополам напишу.

VD>Вот здесь находится код парсера на том самом совершенно неизвестном тебе языке. Это парсер строчного калькулятора (вычисляющего арифметические выражения). Погляди его плиз, и поделись своим мнением многое ли ты в нем не понял.
Что это такое? Зачем оно в проекте?

VD>Потом представь, что все обработчики могут быть объявлены абстрактным и написаны на знакомом тебе языке в классе-наследнике.
Абстрактные обработчики? Обработчики чего?

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

VD>Тут недавно смотрел по дискавери "Разрушителей легенд" (кстати, просмотрел новую сери

Ну, а мораль такова. Смелость нельзя получить теоретическим путем.

Ну так засунули ведь?

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

Кэр>Именно то, что сказал. Что часто инженер нарыв новый тул пихает его во все щели.

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

Кэр>Нет это была реплика про то, что я хотел получить список реальных задач и я их получил.

Ну так тогда тебе просто прямо надо было об этом спросить

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

Это я в обоснование отсутствия авторитетов. Ничего личного.

AVK>>DSL как технология — практически не ограничена, вопрос лишь в соотношении затрат и бенефитов. Конкретный DSL — безусловно ограничен, ради этого его и делают.

Кэр>КО?

Он самый.

Кэр>Сама задача поддержки разных серверов для конкретных проектов встречается весьма редко.

У кого как. У меня, так в 100% случаев вообще применения SQL серверов

За исключением сайта rsdn, там mssql only.

Кэр>Обычно упирается в банальный бюджет проекта

Это не так дорого, как ты думаешь.

Кэр>потому что специалистов, которые реально могут создать хороший общий знаминатель различных SQL'ей не очень много.

А много и не надо. Вот IT сделал поддержку линка в блт, теперь каждый может написать приложение с поддержкой десятка серверов.

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

Не так страшен черт, как его малюют.

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

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

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

AVK>>Это прямо следует из твоей фразы.

Кэр>У нас версии русских языков несовместимы. Мне даже интересно стало. Каким образом это прямо следует из моей фразы? Особенно в контексте других моих фраз про использование грамматики в РеШарпере в этой теме.

Необходима грамматика — с ней должно быть удобно работать. Этот пункт важен для компилятора Немерле, важен для РеШарпера, важен для тех несчастных душ, которые на волне хайпа будут пытаться свои конфиги записывать как DSL. Совершенно неважен для большинства реальных задач инженера.

Если для реальных задач важен, а для решарпера и немерла не важен, значит решарпер и немерл не реальные задачи. Что я пропустил?

Кэр>Ну давайте теперь займемся софистикой.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>>Надеясь, что с BNF или хотя бы с регулярными выражениями ты знаком?
O>Что-такое BNF — без понятия. Про регулярные выражения что-то слышал краем уха, если надо — с грехом пополам напишу.

До такой степени все же дурака включать не стоит. Если ты не знаешь что такое BNF и РЕ, то тебе никакой парсер в проекте не нужен ибо ты им все арвно воспользоваться не сможешь.

VD>>Вот здесь находится код парсера на том самом совершенно неизвестном тебе языке. Это парсер строчного калькулятора (вычисляющего арифметические выражения). Погляди его плиз, и поделись своим мнением многое ли ты в нем не понял.
O>Что это такое? Зачем оно в проекте?

А если серьезно?

VD>>Потом представь, что все обработчики могут быть объявлены абстрактным и написаны на знакомом тебе языке в классе-наследнике.
O>Абстрактные обработчики? Обработчики чего?

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

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

AVK>>Тогда можно попробовать.

VD>Обана! Это огромный прогресс!

Смотря для кого.

AVK>>Этого мало. Вон IT у себя линк применял из BLT довольно долго. А как янус стали на него перетаскивать — первое время баги сыпались вагонами.

VD>Для чего мало? Для того чтобы назвать немерл очень стабильным? Да, не спорю. Но этого достаточно чтобы признать твои слова про самоубийство не соответствующими действительности.

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

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

Компилятор то ладно. А вот что насчет PEG?

VD>Дык их можно править и так.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>Я предположения "высосал" из нашего обсуждения.

Ну вот не угадал ни разу.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>Он то как раз все знал. И про то что все макрами можно проконтролирвоать тоже знал.

А еще знал, что хороший контроль малой кровью не дастся.

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

Это, кажется, я тебе предлагал. И заодно зафиксировать некий стандарт на базовый набор типа как в лиспе (CLOS?).

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>То есть ты таки отказываешься от своего исходного предложения и соглашаешься со мной в том, что для шарпа проще динамическое решение сделать (на тех же экспрешон трях, к примеру)?

Я думаю, нужно и то и другое.

AVK>>Это совсем несложно. В CCI есть даже всякие обертки, с которыми задача превращается в просто тривиальную.

VD>Ага. Опять преимущественно языком?

Да нет. Пошукай в дотнетном форуме, там кто то реальные примеры применения приводил.

AVK>>Парадокс Блада?

VD>Какой парадокс?

Тот самый, которым ты тут всех ... хм, замучал.

VD> Лично я бинарных файлах копаться не намерен. Ты предложил, ты и пробуй.

Я этим регулярно занимаюсь.

AVK>>И зря офигеваешь. Ничего сложного там нет. А как перепишет генерацию на ET, так совсем все просто станет.

VD>Ага. Ничего. ИТ так и сказал — "Если бы я знал во что это выльется, то не взялся бы.".

Это о линке. Там как раз никакой кодогенерации. Поверь, кодогенератор далеко не самая сложная часть blt.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>>>Во как? Значит твои рассуждения все же не верны

AVK>>Логическую цепочку не продемонстрируешь?

VD>Да ее, на мой взгляд, у тебя в рассуждениях и не было.

Не мою, свою. Как ты пришел к вышепроцитированному выводу.

VD> Сначала "Прелесть XML прежде всего в его предельной простоте, по крайней мере базового слоя.". Потом когда более простой формат который по первому определению вроде как должен проходить появляется: "Потому что не совпадает с генеральной линией партии.".
Давай по порядку.
1) Утверждение "Прелесть XML прежде всего в его предельной простоте, по крайней мере базового слоя." верное
2) Более простой только при аналогичной используемой функциональности. Думал, это очевидно.
3) Про генеральную линию партии говорилось не в плане использования народом, а в плане наличия парсера JSON в составе фреймворка. Очевидно, что последнее — решение в немалой степени политическое. И имеет весьма косвенное отношение к популярности JSON как формата.

VD>Рассуждения становятся ситуационными. Для джейсон наш довод не рабортает, а для ХМЛ работает.

Для JSON тоже работает.

VD>Какая-то странная логика. Да и фрэймворк тут не причем.

Круто. Замечание мое касалось исключительно состава фреймворка. Если фреймворк у тебя не причем, то споришь ты с кем то другим, явно не со мной.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

VD>В чем я тебя обвинил? Я сказал, что твои слова не соответствую действительности

То есть обвинил во вранье.

VD> хотя бы потому, что ХМЛ повинился через год после того как появился Дельфи.

Появился релиз стандарта. А до этого был драфт.

VD> Так же я сказал, что в Дельфи 2 уже поддерживался КОМ и стало быть MSXML в нем можно было использовать сразу как он появился. А появился он в 1997 году.

Ага, все таки в 97. А речь то про 95 или 96. Да и дюже глючным был msxml 1.0 помнится.

VD>Во вранье я тебя тоже не обвинял. Я искренне верил, что ты просто ошибался.

Не вижу как тут можно ошибаться. Тутможно только соврать.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>>Я предположения "высосал" из нашего обсуждения.
AVK>Ну вот не угадал ни разу.

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

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

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

Есть. Ключик пока гипотетический.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>

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

ВВ>>Теперь, я так понимаю, у тебя никаких возражений нет, что в проекте парсера использовать синтаксические макросы не получится?
AVK>Есть. Ключик пока гипотетический.

Причем тут ключик? Речь о том, в проекте парсера люди не смогут использовать *свои* синтаксические макросы. Или мы опять в "угадайку" играем?

А ключик тоже ничего. К тому же, раз уж человек готов его сделать, может, это и несложно. Главное, чтобы ПЕГ вместе с этим ключиком не отвалился

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

Конечно не следует.

Кэр>>Нет это была реплика про то, что я хотел получить список реальных задач и я их получил.

AVK>Ну так тогда тебе просто прямо надо было об этом спросить

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

После этого

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

Может быть можно еще более прямо — я не в курсе

AVK>Это я в обоснование отсутствия авторитетов.

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

AVK>Ничего личного.

Хых

Моя нежная и ранимая душа находится в надежной защите под слоновьей шкурой и толстым слоем сарказма — можете не переживать

AVK>У кого как. У меня, так в 100% случаев вообще применения SQL серверов

За исключением сайта rsdn, там mssql only.

Хм. Мне интересно, а какую бизнес-задачу это решает? Коробочный продукт, который может работать с инсталляцией хоть MSSql, хоть MySql, хоть Oracle? Это правда надо?

Кэр>>потому что специалистов, которые реально могут создать хороший общий знаминатель различных SQL'ей не очень много.

AVK>А много и не надо. Вот IT сделал поддержку линка в блт, теперь каждый может написать приложение с поддержкой десятка серверов.

Я только что вот писал сихронизацию двух баз данных онлайн. Использовал всякие новомодные навороты MSSql типа MERGE, ROW_NUMBER, etc. и различные side-эффекты исполнения этих команды — что выхлоп MERGE можно сохранить во временную таблицу, чтобы почистить staging.

Если бы мне поставили задачу сделать синхронизацию, скажем, в Oracle — я бы лучше написал отдельную либу, которая делает это. Насколько я понимаю тот же blt не предоставляет абстракций для перечисленных конструкций.

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

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

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

AVK>

AVK>Необходима грамматика — с ней должно быть удобно работать. Этот пункт важен для компилятора Немерле, важен для РеШарпера, важен для тех несчастных душ, которые на волне хайпа будут пытаться свои конфиги записывать как DSL. Совершенно неважен для большинства реальных задач инженера.

AVK>Если для реальных задач важен, а для решарпера и немерла не важен, значит решарпер и немерл не реальные задачи. Что я пропустил?

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

AVK>Это не софистика. К чему эти аппеляции к абстрактному инженеру с одной сиськой и одним яйцом?

Разговор начался с моего утверждения, что regex'ы для стандартных задач уже написаны и их писать не надо. А их чтение упрощают визуализаторы.

AVK>Хорошо умеешь решать простые задачи — именно их ты и будешь решать. Все зависит от тебя, а не от наличия миллиона леммингов.

Можете не переживать за уровень моих задач. Мое любопытство и чрезмерная активность заставляет меня постоянно залазить в весьма различные области. Недавно вот я был тут локальным экспертом по С++ CLI, потому что пришлось разобраться с ним по-быстрому, чтобы решить изначальную задачу. Результат, кстати, до сих пор используется в production инфраструктуры поисковика Bing.
Просто мои исследования двигаются насущной необходимостью, которая постоянно больше чем мои возможности.
И просто так на ровном месте я не стану вспоминать теорему Хомского и иерархию грамматик, чтобы делать выводы о полезности PEG — только потому что мне на форуме RSDN так сказали.
А вот список задач, который вы привели — это совершенно другое дело. От этого уже можно плясать в конкретном случае. И это резко повышает шансы, что я посмотрю на PEG более близко.

От:	VladD2	www.nemerle.org
Дата:	17.06.10 19:49
Оценка:

	От:	Wolverrum
	Дата:	18.06.10 08:07
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	18.06.10 08:13
Оценка:

От:	VladD2	www.nemerle.org
Дата:	18.06.10 10:47
Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	18.06.10 11:32
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	18.06.10 20:29
Оценка:

	От:	Воронков Василий
	Дата:	18.06.10 22:20
	Оценка:

	От:	Тролль зеленый и толстый
	Дата:	20.06.10 21:24
	Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	21.06.10 12:02
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	25.06.10 21:40
Оценка:	+1 -1

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	30.06.10 05:15
Оценка:	+1

	От:	Alexander Pazdnikov
	Дата:	02.07.10 15:51
	Оценка:

	От:	LaPerouse
	Дата:	22.06.10 07:55
	Оценка:

	От:	LaPerouse
	Дата:	22.06.10 08:01
	Оценка: