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

Кэр>>>Влад, ты с темы не спрыгивай. Только что ты утверждал, что 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

Автор: VladD2
Дата: 02.07.10

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>>Во как? Значит твои рассуждения

Автор: AndrewVK
Дата: 26.06.10

все же не верны

AVK>Логическую цепочку не продемонстрируешь?

Да ее, на мой взгляд, у тебя в рассуждениях и не было. Сначала "Прелесть XML прежде всего в его предельной простоте, по крайней мере базового слоя.". Потом когда более простой формат который по первому определению вроде как должен проходить появляется: "Потому что не совпадает с генеральной линией партии.".

Казалось бы если логика таки есть, то надо просто согласиться что тезис "что в использовании ХМЛ главное его простота" несостоятелен на том основании, что есть ряд не менее простых форматов которые не получили повсеместного использования. Но вместо этого идет отстаивание логически несостоятельной позиции.

Рассуждения становятся ситуационными. Для джейсон наш довод не рабортает, а для ХМЛ работает.

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


VD>>, и дело вовсе не в простоте формата, а в некой линии партии?

AVK>В случае отсутствия парсера в фреймворке — безусловно многое определяется линией партии. Но это никак тому что по ссылке не противоречит.

Какая-то странная логика. Да и фрэймворк тут не причем. Бритву Окама помнишь? У нас есть два объяснения, сложное и простой. Сложно приплетает партии (которые есть не везде, кстати), простоту формата и еще что-то и есть простое — "Есть апи — используют, нет — не используют или используют редко". Конечно можно сказать что тотальное наличие ХМЛ-парсеров определяется стандартностью ХМЛ. Я с этим так же охотно соглашусь. Но уверен, что если не было бы этих самых АПИ, то стандартность не помогла бы. Вот в С++-стандарт входило много интересного. В новом стандарте кое что выбрасывают, так как в реальной жизни это кое-что не использовалось.

VD>>А это уже не важно.

AVK>То есть если факты не соответствую теории, тем хуже для фактов?

Ну, получается, что так. По крайней мере если послушать тебя.

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

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

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

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

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

ВВ>Тогда я вообще его не понимаю.

Да просто ты по-другому приоритеты ставишь, а он о реальны причинах говорить не очень хочет.

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

Ну, а почему не хочет — это уже отдельный разговор.

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

Тут недавно смотрел по дискавери "Разрушителей легенд" (кстати, просмотрел новую сери ), так вот там они проверяли миф, что мол если нагреть свинец до определенной температуры (что-то там выше 400 градусов), обмакнуть руку в воде, то можно засунуть ее в расплавленный свинец, вынуть и тебе ничего не будет. Миф оказался правдой. Более того он как-то там научно объясняется. Эти орлы проделали эксперимент на сосиске, который показал, что таки да, с сосиской все ОК. Тогда они решились засунуть свои руки в расплавленный свинец. Они точно знали, что ничего плохого не произойдет. Но видил бы ты их рожи когда они это делали! Вот за что люблю эту передачу! Ну, а мораль такова. Смелость нельзя получить теоретическим путем.

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

O>Тут ты ошибаешься. Народ офигачивать не будет, скажет, что не знает че это такое и нафига нам оно надо.

Ага. Я ошибась. В прошлый раз я тут с Ziaw спорил. Он тоже говорил что я ошибаюсь... А сейчас вот он близок к релизу NRails

Автор: Ziaw
Дата: 24.06.10

(аналог Ruby on Rails) .

Классный, кстати, фрэймворк получился!

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

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

Можно вопрос лично к тебе?
Давай представим что ты и есть тот самый народ. Надеясь, что с BNF или хотя бы с регулярными выражениями ты знаком? Тогда давай проведем один эксперимент.

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

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

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

VD>Можно вопрос лично к тебе?
Можно.

VD>Давай представим что ты и есть тот самый народ.
Окей, будем простым народом.

VD>Надеясь, что с BNF или хотя бы с регулярными выражениями ты знаком?
Что-такое BNF — без понятия. Про регулярные выражения что-то слышал краем уха, если надо — с грехом пополам напишу.

VD>Вот здесь находится код парсера на том самом совершенно неизвестном тебе языке. Это парсер строчного калькулятора (вычисляющего арифметические выражения). Погляди его плиз, и поделись своим мнением многое ли ты в нем не понял.
Что это такое? Зачем оно в проекте?

VD>Потом представь, что все обработчики могут быть объявлены абстрактным и написаны на знакомом тебе языке в классе-наследнике.
Абстрактные обработчики? Обработчики чего?

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

VD>Тут недавно смотрел по дискавери "Разрушителей легенд" (кстати, просмотрел новую сери ), так вот там они проверяли миф, что мол если нагреть свинец до определенной температуры (что-то там выше 400 градусов), обмакнуть руку в воде, то можно засунуть ее в расплавленный свинец, вынуть и тебе ничего не будет. Миф оказался правдой. Более того он как-то там научно объясняется. Эти орлы проделали эксперимент на сосиске, который показал, что таки да, с сосиской все ОК. Тогда они решились засунуть свои руки в расплавленный свинец. Они точно знали, что ничего плохого не произойдет. Но видил бы ты их рожи когда они это делали! Вот за что люблю эту передачу! Ну, а мораль такова. Смелость нельзя получить теоретическим путем.

Ну так засунули ведь?

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

Кэр>Именно то, что сказал. Что часто инженер нарыв новый тул пихает его во все щели.

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

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

Ну так тогда тебе просто прямо надо было об этом спросить

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

Это я в обоснование отсутствия авторитетов. Ничего личного.

AVK>>DSL как технология — практически не ограничена, вопрос лишь в соотношении затрат и бенефитов. Конкретный DSL — безусловно ограничен, ради этого его и делают.

Кэр>КО?

Он самый.

Кэр>Сама задача поддержки разных серверов для конкретных проектов встречается весьма редко.

У кого как. У меня, так в 100% случаев вообще применения SQL серверов За исключением сайта rsdn, там mssql only.

Кэр>Обычно упирается в банальный бюджет проекта

Это не так дорого, как ты думаешь.

Кэр>потому что специалистов, которые реально могут создать хороший общий знаминатель различных SQL'ей не очень много.

А много и не надо. Вот IT сделал поддержку линка в блт, теперь каждый может написать приложение с поддержкой десятка серверов.

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

Не так страшен черт, как его малюют.

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

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

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

AVK>>Это прямо следует из твоей фразы.

Кэр>У нас версии русских языков несовместимы. Мне даже интересно стало. Каким образом это прямо следует из моей фразы? Особенно в контексте других моих фраз про использование грамматики в РеШарпере в этой теме.

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

Если для реальных задач важен, а для решарпера и немерла не важен, значит решарпер и немерл не реальные задачи. Что я пропустил?

Кэр>Ну давайте теперь займемся софистикой.

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

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

VD>>Надеясь, что с BNF или хотя бы с регулярными выражениями ты знаком?
O>Что-такое BNF — без понятия. Про регулярные выражения что-то слышал краем уха, если надо — с грехом пополам напишу.

До такой степени все же дурака включать не стоит. Если ты не знаешь что такое BNF и РЕ, то тебе никакой парсер в проекте не нужен ибо ты им все арвно воспользоваться не сможешь.

VD>>Вот здесь находится код парсера на том самом совершенно неизвестном тебе языке. Это парсер строчного калькулятора (вычисляющего арифметические выражения). Погляди его плиз, и поделись своим мнением многое ли ты в нем не понял.
O>Что это такое? Зачем оно в проекте?

А если серьезно?

VD>>Потом представь, что все обработчики могут быть объявлены абстрактным и написаны на знакомом тебе языке в классе-наследнике.
O>Абстрактные обработчики? Обработчики чего?

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

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

AVK>>Тогда можно попробовать.

VD>Обана! Это огромный прогресс!

Смотря для кого.

AVK>>Этого мало. Вон IT у себя линк применял из BLT довольно долго. А как янус стали на него перетаскивать — первое время баги сыпались вагонами.

VD>Для чего мало? Для того чтобы назвать немерл очень стабильным? Да, не спорю. Но этого достаточно чтобы признать твои слова про самоубийство не соответствующими действительности.

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

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

Компилятор то ладно. А вот что насчет PEG?

VD>Дык их можно править и так.

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

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

ВВ>Я предположения "высосал" из нашего обсуждения.

Ну вот не угадал ни разу.

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

VD>Он то как раз все знал. И про то что все макрами можно проконтролирвоать тоже знал.

А еще знал, что хороший контроль малой кровью не дастся.

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

Это, кажется, я тебе предлагал. И заодно зафиксировать некий стандарт на базовый набор типа как в лиспе (CLOS?).