Здравствуйте, AndrewVK, Вы писали:
AVK>>>Зачем рантайм? Нужен кодогенератор банальный. Например в виде шаблона Т4.
VD>>Можно и так.
AVK>Я бы сказал нужно,
А я бы сказал, что как раз людям нужно что-то что можно из кода легко позвать. Были бы макросы, тогда можно было бы на них сбацать. А без них приемлемым решением будет как раз рантаймное.
AVK>если тебе интересно чтобы этим хоть кто то пользовался.
Мне не хочется. У меня уже есть. Я тут другим идеи подкидываю.
AVK>Можно и взаимодействие сделать. При помощи expression tree. Не так красиво, как со спецсинтаксисом, но вполне юзабельно. Irony видел?
Я не очень представляю себе как будет на практике выглядеть смесь из деревьев выражений и кодогенерации на Т4, но раз речь зашла об деревьях выражений, то это уже по определению будет рантайм-решением (хотя бы частично), так как они во время компиляции недоступны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, AndrewVK, Вы писали:
AVK>Это как? Ты же утверждаешь, что xml используют только из-за инструментария.
Дык ини-файлы тоже. Наличие АПИ делает их резко привлекательными. Если бы оного не было, то многие бы забили на их использование даже при условии, что эти форматы во всех остальных отношениях подходят.
Далее если подумать, то становится очевидным, что если бы вопрос создания собственного формата не привносил бы больших сложностей, т.е. если бы формат можно было бы быстренько описать с помощью PEG (с которым, предположим, человек хорошо знаком) и легко интегрировать в свое приложение, то многие предпочли бы специализированные форматы вместо ХМЛ-я или ини-файлов.
VD>>Какой вывод? На всех твои слова обобщать нельзя.
AVK>Но и твои тоже, не так ли?
Нет. Мои слова не зависят от моего мнения. Они являются чистой индукцией.
VD>>Если так мыслить, то брэйнфак понять проще, так как его грамматика проще чем скажем у С.
AVK>Схема, в отличие от брейнфака, вполне человекочитаема и не лишена средств декомпозиции. Так что аналогия кривая.
Я ее видел. Но вот описывать ее мне тяжело.
VD>>Актись. Какой на фих ХМЛ во времена дельфи 1.0? VD>> Дельфи 1.0 появилась в 1995-ом, а ХМЛ в 1996.
AVK>Вот поэтому парсеров готовых и не было.
Не было не только парсеров, но и самого ХМЛ-я. Уверен, что о ХМЛ-е ты узнал примерно в то же время когда узнал о дотнете. А к этому времени было уже и Дельфи 2, и даже 3, которые работали с КОМ-ом, так что можно было спокойно взять МС-ный парсер.
AVK>Да нет, в реальности тоже. Ты ж сам базовую грамматику xml приводил. Рукопашный парсер с рекурсивным спуском не сильно сложнее.
Сольно. Раз эдак в 10. Его без подготовки мало кто быстро написать может. А те кто смогут скорее всего не будут, так как другими задачами занимаются.
Вот ты лично хотя бы один ХМЛ-парсер написал?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, AndrewVK, Вы писали:
Кэр>>Почему? AVK>Потому что когда в руках молоток, все вокруг кажется гвоздями.
Вы меня тут так процитировали, что я даже растерялся Я спрашивал почему вы решили, что не изучаю ничего нового. А по поводу молотка — я могу также сказать, что когда в руках появился новый блестящий молоток — то все кажется новыми гвоздями для нового молотка Я просто прагматично подхожу к процессу.
Кэр>> Просто я не кидаюсь вообще на все новое. AVK>На вообще все — не надо. Но не глядеть на новое вовсе или глядеть в малых дозах — чревато.
Да, рандомные забеги в смежные области необходимы. Но не нужно также преувеличивать их значение.
Кэр>> Так как PEG'и мне прямо сейчас не нужны AVK>Тут Влад постоянно парадокс Блаба упоминает. Суть в том, что пока ты не разберешься примерно в технологии, тебе практически всегда будет казаться, что она не нужна.
Именно поэтому я и спрашивал у тех, кто разобрался для решения каких задач нужна технология
Кэр>>Ну я и тоже с довольно общих позиций речь веду. AVK>Ты слишком многое строишь на том, что у тебя лично нет таких задач. Причем что такое PEG ты понимаешь весьма смутно. В результате — см. выше.
Мне ответили, что PEG — нужны там, где нужны regex, что мы еще обсудим с Владом ниже по ветке. И хотя что такое PEG я понимаю действительно смутно — regex мне нужны редко
Кэр>>Так как сама задача разбора текста стоит редко AVK>Не так редко, как тебе кажется.
Дык возвращаемся к исходному вопросу. Я утверждаю, что разбор текста важен:
1. Проверка шаблона (различные верификаторы). Для большинства стандартных случаев уже просто есть regex, которые работают.
2. Эмпирическое выделение/разделение кусков текста. Выкусить конкретное значение аттрибута, или имя класса, или еще что-то в таком духе. Или порезать тот же SQL на блоки команд. Полная грамматика языка тут не нужна. Хватает эвристик на пару с regex'ами.
3. Полноценный разбор текста, построение AST, анализ структур и прочее. Необходима грамматика — с ней должно быть удобно работать. Этот пункт важен для компилятора Немерле, важен для РеШарпера, важен для тех несчастных душ, которые на волне хайпа будут пытаться свои конфиги записывать как DSL. Совершенно неважен для большинства реальных задач инженера.
Что я пропустил? Что тут не так?
AVK>При чем тут грамматика? Речь об инструментарии, а не о грамматике вобщем. Регексы это тоже грамматика, только куцая.
Речь о том, где инструментарий применим.
Кэр>>Еще раз — для стандартных задач писать regex не имеет смысла. AVK>Кто такие стандартные задачи? Валидация емейла — стандартная задача?
Да.
Re[23]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, VladD2, Вы писали:
VD>Рад за тебя. Что будешь делать когда для другой задачи никто специализированного решения не напишет?
Влад, ты с темы не спрыгивай. Только что ты утверждал, что HTML невозможно парсить regex'ами. Я тебе привел работающий пример, который хорошо справляется с этой задачей. Более того через него написан компилятор Asp.NET шаблонов.
Когда мне потребуется что-то специализированное — то я и поищу что-то специализированное. А пока мне и упомянутое решение пригодилось в практике всего пару раз.
Re[14]: [Голосование] Понимаете ли вы формальные грамматики?
И ты чертовски крут если сможешь реализовать ее в полностью рабочем виде хотя бы за день, даже при условии что ты будешь использовать генератор парсеров. Вручную же это...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, VladD2, Вы писали:
VD>Ошибешься, это PEG. Он описывает парсер, а не грамматику языка. VD>Но на EBNF (расширенный BNF) — это действительно похоже. Разница в трех вещах:
Спасибо, выглядит интересно.
VD>А зачем в одну строчку то? Ты на С++/C# тоже все в одну строчку записываешь? VD>И кто тебе это рекламировал?
Ошибся, там о другом речь шла.
VD>На C# это пока что никак не будет выглядеть, так как я пока не знаю о решениях для шарпа которые можно использовать прямо из кода. Но в принципе оно может мало чем отличаться от того что ты делаешь с регулярными выражениями. Разве что ты сможешь все же произвести декомпозицию своего паттерна, если он станет сложным.
Меня пседво код устроит. Мне принцип понять интересно.
Re[15]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, VladD2, Вы писали:
VD>И ты чертовски крут если сможешь реализовать ее в полностью рабочем виде хотя бы за день, даже при условии что ты будешь использовать генератор парсеров. Вручную же это...
Изрядная часть того, что ты тут привел избыточно. Собственно, давай возьмем и разберемся что есть что в этой грамматике.
Поддержка процессора? Очевидно, что у нас ее не будет по причине отсутствия процессора
Квалидентов у нас нет и быть не может, ибо нет пространств имен, о чем заявлялось изначально.
ХМЛ референс убираем по тем же причинам
Поддержку двойных и одинарных кавычек можно и оставить, хотя половина людей использующих ХМЛ даже не знает, что в нем можно одинарные кавычки использовать.
Что там осталось? Не так уж и много.
Причем речь, повторюсь, идет о "формате для конфигов" по сути, позволяющим хранить иерархические данные. Так что я правда не вижу ничего невозможного.
Два дня где-то я писал парсер JSON-а по спекам, причем врукопашную, с рукопашной же токенизацией. На третий день сделал генератор и сериализатор. Сериализатор вяло допиливался и фиксился еще недели две. Все остальное работало с минимальными фиксами после базовых тестов.
Re[24]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, Кэр, Вы писали:
Кэр>Влад, ты с темы не спрыгивай. Только что ты утверждал, что HTML невозможно парсить regex'ами.
И продолжаю это делать.
Кэр>Я тебе привел работающий пример, который хорошо справляется с этой задачей.
Ты привел пример какого-то левоего класса на который даже документации нет, который никакого отношения к регулярным выражениям не имеет.
Кэр>Более того через него написан компилятор Asp.NET шаблонов.
Тебе, кстати, уже заметил, что компилятор шаблонов Asp.NET работает весьма криво. Так что не ясно что твои слова могут доказывать.
Кэр>Когда мне потребуется что-то специализированное — то я и поищу что-то специализированное. А пока мне и упомянутое решение пригодилось в практике всего пару раз.
Нет проблем. Только не называй его регулярными выражениями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Кэр, Вы писали:
Кэр>>Это не так в компиляторах — но там и PEG использовать как-то не с руки, если там нет разделения на токенизатор и сотоварищи. Какой-нибудь ANTLR подойдет лучше на мой взгляд.
DM>Ващета никто не мешает в PEG разбирать не последовательность символов, а последовательность токенов от лексера. Я так делал как раз.
Единственный смысл разбирать лексемы PEGом — композиция грамматик.
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
Re[21]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Кэр, Вы писали:
Кэр>>Выглядит неплохо.
VD>Вот и я о том же. Заметь, не сильно сложнее регекспов.
Кстати, вот эта строка: VD>
VD>!(@"\" / @"\""") any
VD>
неверна, так как оператор "/" просто не выполнит второе вхождение в случае обранужения \". Чтобы правило разбирало то что требуется нужно поменять подправила местами:
!(@"\""" / @"\") any
Тогда будет производиться попытка распознать последовательность \" и если это не она, то просто \.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, Кэр, Вы писали:
Кэр>Вы меня тут так процитировали, что я даже растерялся
Смысл оставлять длинные простыни цитат? Ты уже сам не помнишь о чем писал?
Кэр> Я спрашивал почему вы решили, что не изучаю ничего нового
Все ходы записаны:
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"/>, чем такое:
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>>
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Так, повторюсь, какая проблема? Если парсер действительно хорош и удобен и нет каких-то религиозных запретов, использовать в проекте Немерле.
Проблема в выделенном.
ЗЫ
Когда-то давно я изучал экономику по учебнику одного западного орла. Там был один очень любопытыный пример. Касался он пошлин. Точно уже я его не вспомню, но суть была примерно такая... Есть страна которая держит высокие ввозные пошлины на нефть. У этой страны есть много зерна. И тут приходит орел и говорит — "Я нашел охренительный способ получения дизельного топлива из зерна! Очень дешевый и эффективный!". Его спрашивают — "Какой!". Он отвечает — "Нам нужно продавать зерно зарубеж и на эти деньги покупать нефть или диз.топливо.".
Твое сообщение почему-то напомни об этом примере.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Грамматика у Немерле, конечно же, более сложная, однако я действительно не понимаю, как это может помешать в данном случае.
Да ладно. Неужели правда не понимаешь?
Тут все очень просто. В комманде работает много народа. Большая часть этого народа религиозных убеждений не имеет, и дальше своего носа не смотрит. Выполняет свою работу и идет домой.
Теперь представь что может произойти. Приносит им Андрей казалось бы безобидную тулзу-генератор парсеров. Народ на ней офигачивает средней сложнсоти парсер оформляя обработку семантики (как и раньше) на шарпе.
Но народ ведь по определению ленив. Увидев, что в этой тулзе создаются классы он может сказать себе — "О! А зачем мне обработку семантики куда-то выносить? Дай как я мальца сэкономлю и реализую ее прямо здесь". Пробуют... и к их немалому удивлению все получается не хуже чем на шарпе. Пока пробуют они пару раз залезают в документацию и/или статьи и обнаруживают, что у этой тулзы есть фишки которые очень пригодились бы в шарпе. Далее следует еще более крамольная мысль — а не попробовать ли част логики оформить на этом диковинном языке? Пробуют... и, о чудо, получается лучше чем на шрпе! Дальше они начинают преставать к Андрею, мешая ему работать, с вопросами вроде "А чё мы вообще все на этом языке не пишем?". Это приводит к полной остановке работы флэймам и как развалу к полному развалу всего рабочего процесса.
ВВ>Собственно, на Немерле придется описывать лишь семантические действия, и грамматика там весьма ограниченная.
Сематические действия тоже можно описать абстрактными функциями и реализовать на шарпе.
ВВ>Вообще на Немерле можно писать "как на C#" — и разница будет минимальной.
Вот в этом и кроется самая большая проблема! Другая тулза будет, возможно, намного более неудобной, но на ней нельзя будет писать полноценных программ! А значит нет опасности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, AndrewVK, Вы писали:
AVK>В семантических действиях можно использовать любые возможности Немерле. Со всеми вытекающими.
Объяви их модификатором abstract и нет проблем.
ВВ>>Ты боишься того, что кто-то начнет в таком "проекте парсера" использовать Немерле "на полную катушку"?
AVK>Боюсь.
И очень правильно делаешь! Так оно и будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, VladD2, Вы писали:
VD>Теперь представь что может произойти. Приносит им Андрей казалось бы безобидную тулзу-генератор парсеров. Народ на ней офигачивает средней сложнсоти парсер оформляя обработку семантики (как и раньше) на шарпе. VD>Но народ ведь по определению ленив. Увидев, что в этой тулзе создаются классы он может сказать себе — "О! А зачем мне обработку семантики куда-то выносить? Дай как я мальца сэкономлю и реализую ее прямо здесь". Пробуют... и к их немалому удивлению все получается не хуже чем на шарпе. Пока пробуют они пару раз залезают в документацию и/или статьи и обнаруживают, что у этой тулзы есть фишки которые очень пригодились бы в шарпе. Далее следует еще более крамольная мысль — а не попробовать ли част логики оформить на этом диковинном языке? Пробуют... и, о чудо, получается лучше чем на шрпе! Дальше они начинают преставать к Андрею, мешая ему работать, с вопросами вроде "А чё мы вообще все на этом языке не пишем?". Это приводит к полной остановке работы флэймам и как развалу к полному развалу всего рабочего процесса.
Пороть их надо за это, пороть
Я "не понимаю", потому что в любом проекте, независимо от того, на каком языке он пишется, надо регулярно следить за качеством кода. Если хочешь — каждый зачекиненный файл проверять. Если этого не делать, то проблемы будут в любом случае, и от них не застрахует даже самый тупой язык на свете. В данном случае достаточно "спустить" указания сверху — в каком объеме и качестве используется та или иная утилита. Это если действительно есть какие-либо опасения в том, чтобы писать на Немерле "больше" кода.
Re[26]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, AndrewVK, Вы писали:
AVK>Применения неотлаженного инструмента и наличия внутри него огромного багажа потребных для использования знаний. Если проект не в стиле "сделал за пару месяцев и забыл",
А если из этой серии?
AVK>то применение подобных вещей самоубийственно.
Вот незадача, компилятор немерла на нем же и написан. И этому проекту уже 5 лет. Значит можно выжить после самоубийства?
ВВ>> Ведь в этом "проекте парсера" нельзя будет использовать даже рукописные синтаксические макросы.
AVK>Что значит нельзя? У инструмента такой возможности контроля на данный момент нет.
Да технически — это не проблема. Можно написать один простенький макрос который обеспечит такой контроль. Я в проекте компилятора сделал макрос который контролирует, что все переменные типа Location должны быть изменяемыми. Это же плевое дело. Вот только люди же не идиоты. Они очень быстро начнут задавать вопросы вроде "Зачем мы ограничиваем себя в еде?".
ВВ>>Я правда не понимаю, о чем ты. Не секрет в общем-то, что PEG-парсер добавили в Немерле не в последнюю очередь, чтобы повысить интерес к этому самому Немерле.
AVK>И сильно повысился? Хотя бы сотня пользователей PEG уже есть?
Ну, если честно то макрос писался для себя любимых, так что каких-то мыслей о популяризации не было.
И сотни пользователей наверно еще нет. Более того, не исключено что и баги в нем есть. Но не уж то что-то изменится в твоем мнении, когда появится эта сотня?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: [Голосование] Понимаете ли вы формальные грамматики?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, MasterZiv, Вы писали:
>>>> С целью сбора статистики. Интересно готов ли народ использовать на >>>> практике подобные вещи. Регекспы, при всей их убогости, используются по
MZ>>>Это типа DSL-и строить ?
VD>>И они в том числе. PEG или EBNF помогли бы упростить решение массы задач связанных с разбором строк. В прочем, очень часто эти задачи (не осмысленно) являются частью пути программиста к DSL-ям.
G>Кстати, а что насчет разбора бинарных данных? G>Для Regexp в том виде, в котором мы сейчас видим это довольно сложная задача. Во-первых для бинарных нету "классов символов", что делает regex запись громоздкой, во вторых regexp может только вытащить токены, но не преобразовать их в структуру.
G>Некоторые библиотеки парсер-комбинаторов умеют работать с бинарными данными не хуже чем со строками. Будет ли такая возможность в N?
Я просто прагматично подхожу к процессу.
Оно и понятно — в программировании авторитетов нет. Программист с парой-тройкой лет коммерческого опыта не стесняясь учит жизни дядек, у коих опыт измеряется десятилетиями.
