Здравствуйте, WolfHound, Вы писали:
V>>Я тебе показал, что все необходимые данные в таблице переходов есть, дело за кодом, который их интерпретирует. WH>Ну раз это малое то за пару дней справишься?
Откуда ты взял про "малое"?
И почему ты скипаешь прямые вопросы:
Так ты меня сориентируй по времени, сколько вы потратили на разработку функциональности восстановления?
Whenever parser detects a syntax error, in other words enconters an unexpected terminal symbol, it reports it by calling overridable Events.syntaxError method and then attempts to perform a simple token stream repair. First, it removes an unexpected terminal from the stream. If that was unsuccessful, it inserts before erroneous token one by one terminals that are expected in the current state. If that also has not helped, erroneous terminal is replaced by one that is expected by parser.
V>>В общем, "вынь да положь" из уст тех, кто 100% рабочего времени занимается парсерами и должен как бы представлять весь комплекс задач для минимального примера — это уже странно. Если там всё так просто, чего же вы столько лет на это потратили и продолжаете тратить? WH>Это ты тут говоришь, что там всё просто.
Я говорил и говорю, что суть LR-парсинга проста.
В этом месте любому адекватному разработчику давно должно стать стыдно, если ему для объяснения простого алгоритма нужен некий исходник.
WH>Если там всё так просто, то должен же быть ГЛР парсер который парсит быстрее и восстанавливается лучше, чем нитра.
Покажи мне любой другой проект, типа Нитры.
Не обязательно на GLR.
В общем, опять демагогия на демагогии.
Когда возник тот самый первый спор, ты утверждал, что разрабатываешь "просто генератор парсеров", без конкретной направленности, т.е. пригодный для разных нужд.
Было? — Было.
А для разных нужд бывают подходящи разные алгоритмы.
Пример своего сценария я описывал.
А теперь ты строишь из себя эдакого простачка и закидываешь меня кучей новых вводных. ))
WH>Тем более что нитру на низком уровне я ещё не оптимизировал.
А что ты делал 8 или 10 последних лет?
WH>Да и алгоритм восстановления там можно сделать лучше.
Т.е., даже тебе, занятому именно в этой области 100% рабочего времени, требуется некоторое время, дополнительное к уже потраченному?
Всё веселее и веселее, однако...
WH>Или опять от тебя кроме трёпа ничего не будет?
Да расслабься уже, ты несерьёзен от слова совсем.
Постоянно делаешь попытки увести разговор в сторону, раскидать внимание оппонента.
Всё, чем ты апеллируешь — оно не имеет никакого отношения к изначальному спору.
Точно так же как не имела отношения некая конкретная формула альфа-бленда.
Ну привел я её словесное описание и что?
Ну привел я потом даже её реализацию на шаблонах, и что?
Да аж ничего.
Я сделал это только для того, чтобы заткнуть фонтан твоих оскорблений и попытаться вернуть тебя к сути.
Более ни для чего оно не требовалось.
В общем, через демагогию ты тянешь время и бегаешь от сути обсуждаемого...
А почему??? — правильно!
Потому что не то, что критиковать, а даже просто обсуждать ЛЮБОЕ твоё решение никто не имеет права.
И вот с такими махровыми комплексами приходится иметь дело твоим оппонентам.
А не раз повторённое тобой "лучший в мире парсер" (С) со стороны выглядит вполне однозначно — у тебя на работе есть вполне конкретные к тебе претензии.
Есть такой образ русского Ваньки — один раз вытащил Щуку и потом сидит себе на печи, гордится былыми достижениями, такскаать...
В общем, гениальный человек от просто талантливого отличается тем, что первый таскает каждый день по такой же Щуке.
Причем, буднично и молча.
Первый полезен всегда, второй лишь изредка.
WH>И это при том что я пока даже не требую, чтобы парсер поддерживал изменение грамматики во время разбора (это КЗ).
Вот тот пример, что ты показывал с json: [...] — это не есть изменение грамматики во время разбора.
Т.е., если ты такие вещи называешь "изменениями грамматики", то это уже ой.
То бишь, опять у тебя некая "уникальная терминология".
Это объединение грамматик.
Некоторые генераторы парсеров умеют делать декомпозицию автоматом — разбивают все правила на группы с минимальной связанностью по нетерминалам, т.е. на "подграмматики". Таким образом общий объем таблиц переходов получается меньше. Получить 5-7 таблиц можно аж бегом на большой грамматике.
У тебя подобная функциональность (явное разбиение на подграмматики) делается ручками, я правильно понимаю?
Ну ты там показал исходник, как ты одну грамматику вручную объединил с другой.
WH>А это одно из главных функциональных требований к парсеру нитры.
Ограничить функциональность разбиения грамматик на подграмматики исключительно ручным вариантом?
ЧТД, собсно.
Очередной раз показал своё неумение формулировать задачи.
WH>Плюс есть планы и понимание как добавить ещё некоторые КЗ возможности без заметного снижения производительности.
А с чего ты взял, что разбиение правил из грамматики на слабосвязанные группы должно плохо отражаться на производительности?
Ровно наоборот — производительность от этого обычно повышается.
Здравствуйте, vdimas, Вы писали:
V>Про описание процедуры восстановления для восходящего парсинга ты мог почитать в интернете:
Да чушь всё это. Низкокачественный наивняк.
V>Я говорил и говорю, что суть LR-парсинга проста. V>В этом месте любому адекватному разработчику давно должно стать стыдно, если ему для объяснения простого алгоритма нужен некий исходник.
Простые алгоритмы не работают.
WH>>Если там всё так просто, то должен же быть ГЛР парсер который парсит быстрее и восстанавливается лучше, чем нитра. V>Покажи мне любой другой проект, типа Нитры. V>Не обязательно на GLR.
Я прошу не всю нитру, а только парсер.
ГЛР парсеры же легко делаются. Они же суперпростые и супербыстрые. Вот и покажи хоть один.
V>В общем, опять демагогия на демагогии.
Во-во. Вместо того чтобы показать ГЛР парсер который круто работает ты переводишь стрелки.
V>Т.е., даже тебе, занятому именно в этой области 100% рабочего времени, требуется некоторое время, дополнительное к уже потраченному? V>Всё веселее и веселее, однако...
Так это по тому что я делаю качественное восстановление.
А какое попало восстановление действительно просто.
Только толку от него нет от слова совсем.
V>Потому что не то, что критиковать, а даже просто обсуждать ЛЮБОЕ твоё решение никто не имеет права.
Обсуждение должно быть конструктивным. Тогда и я конструктивен.
А когда есть только трёп, противоречащий всем научным работам, которые я видел, да ещё и таким тоном как будто ты всё знаешь то имеем то что имеем.
WH>>И это при том что я пока даже не требую, чтобы парсер поддерживал изменение грамматики во время разбора (это КЗ). V>Вот тот пример, что ты показывал с json: [...] — это не есть изменение грамматики во время разбора.
Вот без этой строчки этого синтаксиса не будет.
using syntax CSharpJson.Extention;//вот тут мы добавили синтаксис json
Так что это если не изменение грамматики во время разбора?
V>Т.е., если ты такие вещи называешь "изменениями грамматики", то это уже ой.
То, что ты опять ничего не понял, наслушался голосов в голове и лезешь поучать совсем не удивляет.
V>Некоторые генераторы парсеров умеют делать декомпозицию автоматом — разбивают все правила на группы с минимальной связанностью по нетерминалам, т.е. на "подграмматики". Таким образом общий объем таблиц переходов получается меньше. Получить 5-7 таблиц можно аж бегом на большой грамматике.
Это мелкие детали реализации парсеров работающих на других принципах.
В нитре не нужно, ибо таблиц нет.
V>У тебя подобная функциональность (явное разбиение на подграмматики) делается ручками, я правильно понимаю?
А это логический уровень.
Он нужен для того чтобы человек мог написать вот такую строку
using syntax CSharpJson.Extention;//вот тут мы добавили синтаксис json
V>Ограничить функциональность разбиения грамматик на подграмматики исключительно ручным вариантом? V>ЧТД, собсно. V>Очередной раз показал своё неумение формулировать задачи.
Голоса в голове у тебя очень разговорчивые.
WH>>Плюс есть планы и понимание как добавить ещё некоторые КЗ возможности без заметного снижения производительности. V>А с чего ты взял, что разбиение правил из грамматики на слабосвязанные группы должно плохо отражаться на производительности? V>Ровно наоборот — производительность от этого обычно повышается.
Опять голоса. Я говорю про добавление контекстно-зависимых возможностей в парсер.
А ты про чёрт знает, что.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
V>>Про описание процедуры восстановления для восходящего парсинга ты мог почитать в интернете: WH>Да чушь всё это. Низкокачественный наивняк.
Мде...
По-прежнему, единственным мотивом для меня потратить значительное кол-во часов для демонстрации — это попытаться тебя заинтересовать.
И ладно бы у тебя было ну хотя бы нейтральное ко всему этому отношение или интерес к изучению предмета.
Пока что ты тщательно демонстрируешь противоположное.
V>>Я говорил и говорю, что суть LR-парсинга проста. V>>В этом месте любому адекватному разработчику давно должно стать стыдно, если ему для объяснения простого алгоритма нужен некий исходник. WH>Простые алгоритмы не работают.
1. А как же лексер работает?
2. Простые алгоритмы допиливаются.
WH>Я прошу не всю нитру, а только парсер. WH>ГЛР парсеры же легко делаются.
Прост сам алгоритм разбора, но задача генерирования парсера из абстрактного описания не проста — такая же как и для других алгоритмов.
V>>В общем, опять демагогия на демагогии. WH>Во-во. Вместо того чтобы показать ГЛР парсер который круто работает ты переводишь стрелки.
Я ни разу не обещал показать исходник, я лишь делился полученными результатами.
Чтобы я что-то тебе показал, меня надо мотивировать потратить на это значительное кол-во часов.
И с последним у тебя явные проблемы.
V>>Т.е., даже тебе, занятому именно в этой области 100% рабочего времени, требуется некоторое время, дополнительное к уже потраченному? V>>Всё веселее и веселее, однако... WH>Так это по тому что я делаю качественное восстановление. WH>А какое попало восстановление действительно просто. WH>Только толку от него нет от слова совсем.
Мде...
Если я тебе говорю, что таблица для восходящего разбора СОДЕРЖИТ необходимые данные для восстановления (и это действительно так, инфа проверяемая), а ты в ответ "а покажите-ка мне восстановление лучше, чем у меня, где я потратил на это годы" — то тебе сразу красная карточка за неумение вести обсуждение.
Тут не о чем спорить.
Например, в таблице перехода лексера по данному входному символу может не быть переходов из данного состояния. Зато по этой таблице можно посмотреть, по каким символам переходы от данного состояния, таки, есть и подсказать их.
Таблицы для LR-разбора по семантике фактически равны таблице лексера, в отличие от таблиц, скажем, для LL(1) разбора на ДКА.
Понимание этих вещей требует куда как меньших умственных затрат, чем на твой пресловутый альфа-блендинг.
А так-то да. "Качественное восстановление" — это всегда набор эвристик по имеющимся данным.
V>>Потому что не то, что критиковать, а даже просто обсуждать ЛЮБОЕ твоё решение никто не имеет права. WH>Обсуждение должно быть конструктивным. Тогда и я конструктивен.
Конструктив — это обмен технической информацией.
У тебя же сплошной стиль "а у вас зато молоко убежало". ))
WH>А когда есть только трёп, противоречащий всем научным работам, которые я видел
Ну так покажи мне исходники программ, упоминаемых в тех научных работах?
Потому что я тут тоже видел "научную" реализацию Эрли... Но как программист скажу — низачот.
Или брал я как-то один "научный" исходник по ИИ, так там и вовсе с пол-тыка в ~8 раз скорость поднял.
WH>да ещё и таким тоном как будто ты всё знаешь то имеем то что имеем.
Ты мне своего не приписывай.
Таким тоном, наоборот, разговаривают когда НЕ желают узнавать что-то новое.
У меня чаще простое любопытство и дележ своим опытом.
WH>>>И это при том что я пока даже не требую, чтобы парсер поддерживал изменение грамматики во время разбора (это КЗ). V>>Вот тот пример, что ты показывал с json: [...] — это не есть изменение грамматики во время разбора. WH>Вот без этой строчки этого синтаксиса не будет. WH>
WH>using syntax CSharpJson.Extention;//вот тут мы добавили синтаксис json
WH>
WH>Так что это если не изменение грамматики во время разбора?
А в C# вот тут:
unsafe {
fixed(char * a = str) {...}
}
?
А какая грамматика получается после объединения контекстно-свободных грамматик?
V>>Некоторые генераторы парсеров умеют делать декомпозицию автоматом — разбивают все правила на группы с минимальной связанностью по нетерминалам, т.е. на "подграмматики". Таким образом общий объем таблиц переходов получается меньше. Получить 5-7 таблиц можно аж бегом на большой грамматике. WH>Это мелкие детали реализации парсеров работающих на других принципах. WH>В нитре не нужно, ибо таблиц нет.
Ну и как ты собрался сравнивать реализацию на goto/call и табличную?
Сравнивать надо на одинаковой технике реализации, чтобы сравнение было адекватным.
Так-то любую табличную реализацию можно перевести на goto/call и обратно, дело в трудоёмкости.
Но скорость до 2-х раз может отличаться сходу даже по идентичному алгоритму разбора, только лишь за счёт техники реализации.
V>>Ровно наоборот — производительность от этого обычно повышается. WH>Опять голоса. Я говорю про добавление контекстно-зависимых возможностей в парсер.
Ты говоришь про semantic actions, которые влияют на сам парсер.
ОК.
Поинт понятен и отметается сходу тоже, бо такое можно практически при любой технике парсинга, т.е. делаем вид, что этого "аргумента" не было, не засоряем себе голову.
Здравствуйте, vdimas, Вы писали:
WH>>Я прошу не всю нитру, а только парсер. WH>>ГЛР парсеры же легко делаются. V>Прост сам алгоритм разбора, но задача генерирования парсера из абстрактного описания не проста — такая же как и для других алгоритмов.
Это тривиальная задача. Делается, вообще не приходя в сознание.
Настоящая веселуха начинается, когда начинаешь после ошибок восстанавливаться.
V>Я ни разу не обещал показать исходник, я лишь делился полученными результатами.
Я уже даже не прошу показать твой код.
Покажи хоть чей. Там же по твоим утверждениям всё просто.
Значит кто-то должен был это сделать.
V>Чтобы я что-то тебе показал, меня надо мотивировать потратить на это значительное кол-во часов. V>И с последним у тебя явные проблемы. Сколько десятков часов ты уже потратил отвечая на мои сообщения?
V>Если я тебе говорю, что таблица для восходящего разбора СОДЕРЖИТ необходимые данные для восстановления (и это действительно так, инфа проверяемая), а ты в ответ "а покажите-ка мне восстановление лучше, чем у меня, где я потратил на это годы" — то тебе сразу красная карточка за неумение вести обсуждение.
В нисходящих парсерах это всё тоже доступно без проблем. Только этого мягко говоря недостаточно.
V>Конструктив — это обмен технической информацией. V>У тебя же сплошной стиль "а у вас зато молоко убежало". ))
Так от тебя никакой информации нет. Одно хвастовство которое противоречит всем работам, которые я читал.
WH>>Вот без этой строчки этого синтаксиса не будет. WH>>
WH>>using syntax CSharpJson.Extention;//вот тут мы добавили синтаксис json
WH>>
WH>>Так что это если не изменение грамматики во время разбора? V>А в C# вот тут:
C# тупо парсит всё. А на этапе типизации говорит
Pointers and fixed size buffers may only be used in an unsafe context
А у меня идёт именно загрузка новой грамматики. О которой автор основной грамматики в общем случае даже не догадывается.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
V>>Прост сам алгоритм разбора, но задача генерирования парсера из абстрактного описания не проста — такая же как и для других алгоритмов. WH>Это тривиальная задача. Делается, вообще не приходя в сознание.
Ну вот вы делали генератор для ПЕГ более 2-х лет.
Я не считаю, что 2 года — это трививально.
Для моего случая полноценных минимум 3-4 рабочих дня вынь да положь.
Это если охота именно погонять, а не "просто взглянуть на алгоритм".
WH>Настоящая веселуха начинается, когда начинаешь после ошибок восстанавливаться.
Т.е. остальные 6 лет ты потратил на обыгрывание восстановления после ошибок?
По-моему, ты сам себя закопал только что.
WH>Покажи хоть чей. Там же по твоим утверждениям всё просто.
Хоть чей ты можешь взглянуть и без меня.
WH>Значит кто-то должен был это сделать.
Ну вот Бизон делает GLR, смотрел?.
Там лексер кладёт код текущего разобранного символа-нетерминала в глобальную переменную.
Потом вызывается парсер, который читает эту глобальную переменную.
Догадайся с одного раза, какая будет "константа" в такой реализации. ))
Разумеется, сам алгоритм парсинга тут не при чем, это просто наследство архитектуры 20-тилетней давности, где проги ранее почти всегда собирались с однопоточным рантаймом и где скорость компиляции больше ограничивалась быстродействием дисковой подсистемы.
V>>Чтобы я что-то тебе показал, меня надо мотивировать потратить на это значительное кол-во часов. V>>И с последним у тебя явные проблемы. WH>Сколько десятков часов ты уже потратил отвечая на мои сообщения?
По 3-5 мин на сообщение.
Одному человеку редко отвечаю более 2-х сообщений в день, разве что по выходным.
Когда писал сниппет кода про альфа-блендинг потратил минут на 5-7 больше.
Позже перечитал, увидел кучу описок и поисправлял.
В общем, я пишу сюда в кач-ве "отдыха" от программирования. ))
Некоторые в этот самый момент на перекур ходят, к примеру...
V>>Если я тебе говорю, что таблица для восходящего разбора СОДЕРЖИТ необходимые данные для восстановления (и это действительно так, инфа проверяемая), а ты в ответ "а покажите-ка мне восстановление лучше, чем у меня, где я потратил на это годы" — то тебе сразу красная карточка за неумение вести обсуждение. WH>В нисходящих парсерах это всё тоже доступно без проблем. Только этого мягко говоря недостаточно.
Недостаточен всего один следующий символ, ты хотел сказать.
Желательно закончить некое выражение, верно?
А для этого нужен текущий стек разбора, верно?
Причем, в рекурсивном спуске у нас стек разбора неявный, т.е. недоступный для его обхода/реинтерпретации, верно?
Поэтому нужен какой-нить другой алгоритм, типа Эрли, который даст стек (стэки) разбора в виде, доступном для обхода.
Так вот, LR-парсеры содержат стек разбора в явном виде.
V>>У тебя же сплошной стиль "а у вас зато молоко убежало". )) WH>Так от тебя никакой информации нет. Одно хвастовство которое противоречит всем работам, которые я читал.
Отчего же стандартом де-факто остаётся старенький Бизон?
WH>>>Так что это если не изменение грамматики во время разбора? V>>А в C# вот тут: WH>C# тупо парсит всё. А на этапе типизации говорит WH>Pointers and fixed size buffers may only be used in an unsafe context
Тем не менее, это тоже был пример контекстно-зависимой грамматики.
Просто я не люблю спекуляции на эти темы.
Почти все известные языки являются КЗ, но парсеры под них — КС.
За счет semantic actions обыгрываются всякие вполне конкретные моменты.
У тебя на "using syntax XXX" происходит "кое-что".
Так вот, вся спекуляция тут в том, что всё это далеко от тру КЗ, где КЗ-правила можно выражать декларативно.
Все эти semantic actions — это всё "черные ящики", у которых их работа описана в документации, а не в доступном для формальной обработки виде.
Кароч, не заставляй коллег делать лишний раз "охотничью стойку", упоминая про КЗ. )))
Давай мы будем говорить про КЗ тогда, когда будет его полноценная формальная поддержка.
Т.е. когда можно будет задавать любой контекст как угодно, а не только через некие ключевые фразы навроде "using syntax".
WH>А у меня идёт именно загрузка новой грамматики. О которой автор основной грамматики в общем случае даже не догадывается.
Надеюсь, в твоём случае, в отличие от Влада, моей фразы "декомпозиция грамматик" будет достаточно для демонстрации понимания того, что при этом происходит?
Мои претензии не к реализации вот этой штуковины (лично я голосую за любую востребованную функциональность). Претензии были к тому, что вот этот момент тоже нифига к обсуждению не относится. Будем считать, что ты кое-чем похвастался, ОК.
We present a hybrid algorithm that chooses between GLR and ordinary LR on a token-by-token basis, thus achieving competitive performance for determinstic input fragments.
На однозначных цепочках они получили скорость LALR(1), который, в свою очередь, работает со скоростью LL(1)/LR(0). А более быстрых алгоритмов парсинга не существует. Не реализаций (руки могут быть и кривыми), а именно алгоритмов.
ЧТД. Собсно, у меня были именно такие же наблюдения и я тебе об этом же и говорил — сначала я оптимизировал свою кухню для максимума быстродействия при единственном варианте (на однозначных цепочках). Потом погонял на конкретных своих данных и соптимизировал структуры данных для случая 2-х одновременно прогоняемых вариантов. В твоей предметной области можно остановиться на "вылизывании" случая одной цепочки.
В общем, я ХЗ что ты там читал про GLR и когда.
Не вижу я никакого "ужаса", который ты приписываешь GLR.
==========
Поискал еще упоминания — многие конторы уже успешно сдохли, например много упоминаний VisualParse++, но скачать неоткуда.
Т.е. такое ощущение, что парсерописательское направление не особо востребовано.
Из живых и активно поддерживаемых на сегодня остались только бесплатные, типа ANTRL, GoldParsingSystem, Coco/R и т.д.
Все платные давно умерли.
Здравствуйте, vdimas, Вы писали:
V>>>Прост сам алгоритм разбора, но задача генерирования парсера из абстрактного описания не проста — такая же как и для других алгоритмов. WH>>Это тривиальная задача. Делается, вообще не приходя в сознание. V>Ну вот вы делали генератор для ПЕГ более 2-х лет. V>Я не считаю, что 2 года — это трививально. Нет. Генерацию первой версии парсера из грамматики я сделал за пару часов.
Остальное время ушло на создание алгоритма восстановления.
V>Т.е. остальные 6 лет ты потратил на обыгрывание восстановления после ошибок? V>По-моему, ты сам себя закопал только что.
Ну так ты покажи алгоритм лучше.
Ну хоть один.
WH>>Покажи хоть чей. Там же по твоим утверждениям всё просто. V>Хоть чей ты можешь взглянуть и без меня.
Так я уже посмотрел. И ничего внятного не нашёл.
По тому тебя треплом и называю.
WH>>Значит кто-то должен был это сделать. V>Ну вот Бизон делает GLR, смотрел?. https://www.gnu.org/software/bison/manual/html_node/Error-Recovery.html
Это же просто звиздец.
You can define how to recover from a syntax error by writing rules to recognize the special token error. This is a terminal symbol that is always defined (you need not declare it) and reserved for error handling. The Bison parser generates an error token whenever a syntax error happens; if you have provided a rule to recognize this token in the current context, the parse can continue.
Это пользователь должен описывать правила восстановления руками. Ахринеть.
1)Это куча мутной работы.
2)Не работает если в грамматике появляются новые правила, которые пользователь не предусмотрел.
Note that discarded symbols are possible sources of memory leaks, see Freeing Discarded Symbols, for a means to reclaim this memory.
Если бы нитра текла меня бы тут на смех всем RSDN'ом подняли.
Ты больше не ссылайся на такое. Это же полнейший неадекват.
И это по твоим утверждениям лучший ГЛР парсер.
WH>>Сколько десятков часов ты уже потратил отвечая на мои сообщения? V>По 3-5 мин на сообщение.
Такие простони? Не верю.
WH>>В нисходящих парсерах это всё тоже доступно без проблем. Только этого мягко говоря недостаточно. V>Недостаточен всего один следующий символ, ты хотел сказать. V>Желательно закончить некое выражение, верно? V>А для этого нужен текущий стек разбора, верно? V>Причем, в рекурсивном спуске у нас стек разбора неявный, т.е. недоступный для его обхода/реинтерпретации, верно?
Неверно. Стек получить не трудно.
Но одного стека мало. Даже DAG'а стеков недостаточно.
V>Поэтому нужен какой-нить другой алгоритм, типа Эрли, который даст стек (стэки) разбора в виде, доступном для обхода.
Нет. Он нужен для того чтобы можно было проверять и оценивать множество вариантов восстановления.
V>Отчего же стандартом де-факто остаётся старенький Бизон?
Покажи как мне ИДЕ на бизоне.
На нитре (хотя она ещё недоделана) уже есть.
V>Тем не менее, это тоже был пример контекстно-зависимой грамматики.
Это был пример чуши.
Все языки, в которых есть требование объявления переменной до использования КЗ по определению.
Мы же говорим про парсеры которые из-за свой вынужденной убогости разбирают строгое надмножество языка.
После чего другой код отсекает те программы, которые языку не принадлежат.
Вот тут именно этот код и сработал.
V>У тебя на "using syntax XXX" происходит "кое-что".
Не кое-что, а загрузка грамматики из внешней ДЛЛ про которую автор языка даже не подозревает и добавление её в текущую грамматику.
V>Кароч, не заставляй коллег делать лишний раз "охотничью стойку", упоминая про КЗ. ))) V>Давай мы будем говорить про КЗ тогда, когда будет его полноценная формальная поддержка.
Делать поддержку КЗ в виде BNF дурь полнейшая.
Просто по тому что написать грамматику языка в виде КЗ не сложно, а охринеть как сложно. Я точно такой инструмент использовать не стану.
V>Надеюсь, в твоём случае, в отличие от Влада, моей фразы "декомпозиция грамматик" будет достаточно для демонстрации понимания того, что при этом происходит?
Нет. Не будет.
Ибо понимания я не вижу.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
V>>Т.е. остальные 6 лет ты потратил на обыгрывание восстановления после ошибок? V>>По-моему, ты сам себя закопал только что. WH>Ну так ты покажи алгоритм лучше. WH>Ну хоть один.
У меня лучшее только то, что я делаю на основной своей работе.
Потому что если оно не будет лучшим в мире, то контора разорится.
Любая контора должна найти свою нишу (или создать её) и быть в этой нише самой лучшей.
Таковы законы жанра.
Тебе за это ЗП платят.
Поэтому, я каждый раз морщусь от твоих "самый лучший" как от кислого лимона.
Потому что по законам жанра бывает так, что даже самое лучшее порой не "выстреливает" за невостребованностью.
Т.е., быть лучшим в целевой области — это никакое не достижение, это условие существования и причина платить тебе ЗП.
Пока что по твоим словам выходит так, что на алгоритм восстановления было потрачено 8 лет?
Тут уже не смеяться, тут плакать надо.
WH>>>Покажи хоть чей. Там же по твоим утверждениям всё просто. V>>Хоть чей ты можешь взглянуть и без меня. WH>Так я уже посмотрел. И ничего внятного не нашёл.
Так искал.
WH>По тому тебя треплом и называю.
По геометрической системе вашего автобана ты должен был быть забанен уже на пару лет примерно по итогам одной этой ветки.
Ты лучше назови себя безруким. В гугл попасть не можешь.
Я за 10 минут нашел живые современные проекты на эту тему: http://www.rsdn.org/forum/philosophy/6722767.1
WH>Это пользователь должен описывать правила восстановления руками. Ахринеть.
Нет, он должен помечать нетерминалы, которые интересуют.
Потому что в правилах до половины нетерминалов могут быть промежуточными, ни разу не интересными для восстановления до них.
WH>1)Это куча мутной работы.
Это примерно такая же работа, как в языке расширенных регулярных выражений отличать конечные правила от промежуточных.
WH>2)Не работает если в грамматике появляются новые правила, которые пользователь не предусмотрел.
Ты про конкретно Бизон или вообще?
Если про Бизон, то там не могут появиться "новые правила".
Если вообще — то храни себе пометки у "существенных" нетерминалов, т.е. храни некоторую метаинформацию.
WH>
WH> Note that discarded symbols are possible sources of memory leaks, see Freeing Discarded Symbols, for a means to reclaim this memory.
WH>Если бы нитра текла меня бы тут на смех всем RSDN'ом подняли.
А как бы она у тебя текла на GC?
И что тебе НЕ понятно из прочитанного:
see Freeing Discarded Symbols, for a means to reclaim this memory.
Есть некие ср-ва по освобождению некоей памяти, ничего военного я тут не вижу.
В C++ ручное управление памятью.
Я вижу что ты опять пытаешься уйти в сторону.
Всё, что ты процитировал — оно вообще не принципиально в этом обсуждении.
Похоже, наличие интернета для тебя бесполезно более чем полностью...
WH>Ты больше не ссылайся на такое. Это же полнейший неадекват. WH>И это по твоим утверждениям лучший ГЛР парсер.
Угу, и опять забегал от "посмотреть на сам алгоритм GLR", до конкретной реализации, а оттуда аж на восстановление.
Задрал, блин.
Слишком скользок.
Я бы тебя уволил, реально.
Ты любую проблематику превращаешь в фарс, замыливаешь суть и отмазываешься до бесконечности.
Быть твоим шефом — это сущее наказание, я ему не завидую.
Здравствуйте, vdimas, Вы писали:
V>У меня лучшее только то, что я делаю на основной своей работе.
Учитывая, что ты тут несёшь я в этом сомневаюсь.
V>Пока что по твоим словам выходит так, что на алгоритм восстановления было потрачено 8 лет?
Это тебе голоса непели.
Плотно этим вопросом я года 3 занимался.
И это очень быстро. Автор ATNLR на свой парсер потратил 25 лет. И результат хуже.
WH>>Так я уже посмотрел. И ничего внятного не нашёл. V>Так искал.
Так ты тоже ничего найти не можешь.
V>Я за 10 минут нашел живые современные проекты на эту тему:
Мне не нужны современные. Мне нужны те которые работают хорошо.
WH>>Это пользователь должен описывать правила восстановления руками. Ахринеть. V>Нет, он должен помечать нетерминалы, которые интересуют. V>Потому что в правилах до половины нетерминалов могут быть промежуточными, ни разу не интересными для восстановления до них.
Вот это и есть ручное описание правил восстановления.
В нитре это делать не нужно. Там даже такой возможности нет.
Всё работает в полностью автоматическом режиме.
Прикинь парсер сам понимает, что нужно удалить, что добавить и где начинается нормальный текст.
WH>>1)Это куча мутной работы. V>Это примерно такая же работа, как в языке расширенных регулярных выражений отличать конечные правила от промежуточных.
Что за бред опять?
WH>>2)Не работает если в грамматике появляются новые правила, которые пользователь не предусмотрел. V>Ты про конкретно Бизон или вообще?
Вообще.
V>Если вообще — то храни себе пометки у "существенных" нетерминалов, т.е. храни некоторую метаинформацию.
Не работает. Ибо в одних случаях они существенные. В других нет.
Нужно на лету разбираться что к чему.
WH>>Если бы нитра текла меня бы тут на смех всем RSDN'ом подняли. V>А как бы она у тебя текла на GC?
Да там не важно на ГЦ она или нет. Там всё и без ГЦ переделать можно. И ничего течь не будет.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
V>We present a hybrid algorithm that chooses between GLR and ordinary LR on a token-by-token basis, thus achieving competitive performance for determinstic input fragments.
V>На однозначных цепочках они получили скорость LALR(1), который, в свою очередь, работает со скоростью LL(1)/LR(0). А более быстрых алгоритмов парсинга не существует. Не реализаций (руки могут быть и кривыми), а именно алгоритмов.
О, а вот это довольно интересно. Генератор произвольных парсеров на C++, способный сгенерировать парсер C++ кода. И кстати вся грамматика C++ у них там задаётся одним простеньким файлом: http://scottmcpeak.com/elkhound/sources/elsa/cc.gr — не похоже на десятки человеко-лет, которыми меня тут пугали, говоря о записи грамматики C++ для Нитры. Правда из описания невозможно понять быстродействие данного продукта... Но в любом случае очень интересное решение.
Кстати, проект не остановился в своём развитие, как может показаться по датам на той страничке, а превратился в это https://github.com/dsw/oink-stack/ — обрёл реально полезное применение. )
Здравствуйте, alex_public, Вы писали:
_>не похоже на десятки человеко-лет, которыми меня тут пугали, говоря о записи грамматики C++ для Нитры.
Я не про парсер говорил. А про всё остальное.
Там реальный ад.
_>Кстати, проект не остановился в своём развитие, как может показаться по датам на той страничке, а превратился в это https://github.com/dsw/oink-stack/ — обрёл реально полезное применение. )
Ты сюда смотрел? https://github.com/dsw/oink-stack/graphs/contributors?from=2009-07-05&to=2017-03-11&type=c
Как по мне проект умер и покрылся пылью.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>не похоже на десятки человеко-лет, которыми меня тут пугали, говоря о записи грамматики C++ для Нитры. WH>Я не про парсер говорил. А про всё остальное. WH>Там реальный ад.
В целом этот их проект (даже не парсер C++, а именно генератор парсеров, позволяющий работать с такими сложными языками) кажется мне весьма интересным. Конечно при условие, что он ещё и работает за приемлемое время (про это мне ничего не известно).
_>>Кстати, проект не остановился в своём развитие, как может показаться по датам на той страничке, а превратился в это https://github.com/dsw/oink-stack/ — обрёл реально полезное применение. ) WH>Ты сюда смотрел? WH>https://github.com/dsw/oink-stack/graphs/contributors?from=2009-07-05&to=2017-03-11&type=c WH>Как по мне проект умер и покрылся пылью.
Ну последние правки несколько месяцев назад — я бы не сказал, что покрывался пылью. Да, активной разработки нет, но что-то там правят понемногу. ))) Кстати, забавный диалог увидел на страничке их проекта (http://dsw.users.sonic.net/oink/index.html) — похоже что товарищи очень хотят найти серьёзную "крышу", но никак не выходит. )))
Здравствуйте, alex_public, Вы писали:
_>А что остальное (ну кроме поддержки в IDE — это отдельный вопрос)?
Поиск имен, разрешение перегрузок, шаблоны итп. И отдельное веселье, когда оно всё сразу там начинаются всякие SFINAE и прочие радости.
_>Ну последние правки несколько месяцев назад — я бы не сказал, что покрывался пылью. Да, активной разработки нет, но что-то там правят понемногу. )))
Как по мне проект был заброшен 7 лет назад.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>А что остальное (ну кроме поддержки в IDE — это отдельный вопрос)? WH>Поиск имен, разрешение перегрузок, шаблоны итп. И отдельное веселье, когда оно всё сразу там начинаются всякие SFINAE и прочие радости.
Шаблоны — это да, отдельная тема. Влад вот правильно писал, что к ним надо сразу подходить как к скриптовому языку, который необходимо выполнить на внутреннем интерпретаторе в процессе компиляции. И кстати, этот язык уже становится не совсем скриптовым (во всяком случае по типизации): я тут поигрался в концепты (они уже полноценно работают в gcc, хотя ещё и не включены в стандарт) — всё отлично работает. Так что язык шаблонов уже получается типизированным. Правда к сожалению опционально — уже написаны огромные горы шаблонного кода без всяких концептов, которые никто не будет переписывать. А так эта возможность по идее должна очень положительно влиять на быстродействие компиляторов C++.
_>>Ну последние правки несколько месяцев назад — я бы не сказал, что покрывался пылью. Да, активной разработки нет, но что-то там правят понемногу. ))) WH>Как по мне проект был заброшен 7 лет назад.
Ой, да пускай даже так, мне как-то вообще не принципиальны все эти мелочи. Вот если бы ты собрал бы этот проектик (не C++ парсер, а который генератор парсеров) и прогнал бы на какой-то своей тестовой грамматике с замером производительности (и сравнением с допустим твоими решениями, ANTLR и скажем тем же bizon'ом) — вот это было бы реально интересно почитать и потом обсудить. А вопрос активности разработки какого-то проектика, про который я только сегодня услышал мне вообще не интересен. )))
Здравствуйте, alex_public, Вы писали:
_>Генератор произвольных парсеров на C++, способный сгенерировать парсер C++ кода. И кстати вся грамматика C++ у них там задаётся одним простеньким файлом: http://scottmcpeak.com/elkhound/sources/elsa/cc.gr — не похоже на десятки человеко-лет, которыми меня тут пугали, говоря о записи грамматики C++ для Нитры.
Ну, там разработчик потратил несколько лет на Elk, насколько я понял.
Вернее, целью была Elsa (парсер С++), а Elk родился как "побочный продукт", т.е. как ядро этого парсера.
_>Кстати, проект не остановился в своём развитие, как может показаться по датам на той страничке, а превратился в это https://github.com/dsw/oink-stack/ — обрёл реально полезное применение.
Да, я тоже считаю, что поддержка набивки кода — это уровень 0.
На нынешнее время должны рулить ср-ва анализа семантики происходящего.
Здравствуйте, WolfHound, Вы писали:
V>>У меня лучшее только то, что я делаю на основной своей работе. WH>Учитывая, что ты тут несёшь я в этом сомневаюсь.
Так и что я "несу"-то?
Покажешь хоть раз или нет?
WH>И это очень быстро. Автор ATNLR на свой парсер потратил 25 лет. И результат хуже.
Автор ATNLR может и меньше чистого времени этим занимался. Он в рабочее время преподаёт, насколько я понял.
И насчет хуже-лучше — это тебе в азы качества ПО надо.
Хуже-лучше определяется только по удовлетворению исходным требованиям.
Если у них не стояла задача разработать ИДЕ для целевых языков программирования, то ты НЕ можешь сравнивать по таким требованиям.
У них вообще не было таких ограничений — разработка пасеров только под ЯП.
Они и над бинарными данными чудесно парсинг делают.
У них стояла задача разработать учебную визуальную модель представления грамматик, по которой (модели) можно визуально отлаживаться в процессе проектирования этих грамматик. В этом плане их результаты лучше твоего, бо у тебя нет таких визуальных ср-в отладки грамматики, как в ANTLR:
А профайлер грамматики у тебя есть?
Каким-либо образом можно узнать в Нитре, на сколько операций парсинга стало больше-меньше на тестовом примере после изменения грамматики?
V>>Потому что в правилах до половины нетерминалов могут быть промежуточными, ни разу не интересными для восстановления до них. WH>Вот это и есть ручное описание правил восстановления. WH>В нитре это делать не нужно. Там даже такой возможности нет. WH>Всё работает в полностью автоматическом режиме. WH>Прикинь парсер сам понимает, что нужно удалить, что добавить и где начинается нормальный текст.
Ну так не описывай восстановление в Бизоне и тоже всё будет автоматом.
Там вообще своё восстановление написать можно, бо кишки Бизона открыты.
Да и не нужно это восстановление при простой компиляции файла, обычно не стоит задача найти все ошибки в файле во время компиляции.
WH>>>1)Это куча мутной работы. V>>Это примерно такая же работа, как в языке расширенных регулярных выражений отличать конечные правила от промежуточных. WH>Что за бред опять?
Что именно ты тут опять не понял?
Какой из терминов вызывал затруднения?
(и кто-то еще пытается обвинять в непонятливости окружающих )
WH>>>Если бы нитра текла меня бы тут на смех всем RSDN'ом подняли. V>>А как бы она у тебя текла на GC? WH>Да там не важно на ГЦ она или нет. Там всё и без ГЦ переделать можно. И ничего течь не будет.
А с чего ты взял, что Бизон течет?
Там сказано, что после ошибки необходимо выполнить такие-то и такие-то действия.
Откуда Бизон знает — закончил ты извлекать инфу об ошибке или еще нет?
Может, ты вручную восстанавливаешься?
Бизон — это больше конструктор, чем полноценная система.
"Заверни" парсер от Бизона в некую высокоуровневую свою среду, которая будет знать, где она закончила разбираться с ошибками, а где уже работает дальше и ву а ля — пусть вызовет прочистку временных данных в нужный момент времени.
=====================
Кароч, ты всё время не туда и не о том.
Давай в сухом остатке, что ты тут задвигал:
1. Простой пример можно сделать быстро. (С)
Согласен, поэтапная работа должна с чего-то начинаться.
С макета.
Например, первый вариант Эрли, показанный когда-то здесь, был ужасен по эффективности.
На последующих этапах можно смотреть, где и что, как подкрутить и чем вызваны тормоза.
Ты же используешь сейчас Эрли, не смотря на весь его ужас в случае примитивной реализации "в лоб"?
Идём далее. Ты настаиваешь:
2. У меня самый быстрый парсер. (С)
Итого, ЛЮБОЙ самый первый вариант/макет ЛЮБОГО парсера будет подвергнут неадекватной обструкции сходу.
Собсно, весь вот этот топик, всё что ты озвучивал — это фактически твоя клятва на крови, что так и будет.
Молоток, чо!
Идём далее. Даже если через несколько итераций и растраты неимоверных запасов терпения для игнора твоего неадеквата/негатива удаётся довести исходный макет до вмеяемой по скорости работы (в сравнении с твоей вылизанной версией Эрли, хотя бы), то у тебя всё-равно приготовлены пути для отступления:
3. Моя Нитра всё-равно лучше всех восстанавливается, я потратил на это много лет. (С)
Итого — а смысл вообще тратить на что-то время СЕЙЧАС, после потраченный тобой кучи лет на восстановление?
Рука-лицо много раз.
Даже если другой алгоритм разбора будет намного эффективнее Эрли и будет близок к LALR(1) по производительности, это уже не имеет никакого значения. Всё, тю-тю, поезд уже ушёл, а ты проспал.
Тебе надо было смотреть на GLR еще тогда, когда я именно что предлагал посмотреть на этот алгоритм как эффективную альтернативу Эрли.
Потому что иначе получается так, что если на RSDN на блюдечке с голубой каёмочкой кто-то выложил реализацию Эрли, то ты её и асилил.
А если тебе так же под нос не поставили — то уже и нет.
Вот такой у тебя в сухом остатке получается бред. Даже не бред, а просто позор какой-то — разрабатывать парсеры и не обладать при этом достаточной эрудицией в своей основной предметной области. Хотя да, само такое положение вещей бредовое, ес-но.
Причем, сам алгоритм GLR я тоже когда-то давно "изобрел" независимо (писал тогда же), бо с интернетом в конце 90-х/начале 2000-х было так себе, т.е. далеко не всё можно было найти в вебе, да и поиск тогда был не особо.
Как и этот фокус с возможностью допиливания исходной идеи параллельного парсинга до эффективной работы на однозначных цепочках (коих до 90% в обычном исходнике). Accent и Elk тогда тоже еще не были опубликованы.
Да и какая разница, опубликован ли Accent или Elk? И какая разница, насколько активны эти проекты прямо сейчас (вон ты рядом пинал даже на это — опять рука лицо).
Мои исходные утверждения были и есть истинными и без этих публикаций.
Да мне вообще тогда хотелось лишь обсудить найденные мною трюки, а обсудить на сайте их не с кем.
Вот вы с Владом подвернулись тогда, бо тоже носились с парсингом. Но из вас еще те обсуждальщики, угу. У вас же философия — "за пределами МКАДА жизни нет". Т.е., что вы руками сами не трогали, того и не существует... Скучные вы, кароч... )) Не любопытные. И ладно если еще лет 10 назад, когда тебе было 26/27 я мог списывать твою неадекватность на подзадержавшееся детство и некую сумбурность в голове, то сейчас такая сумбурность/непоследовательность — это уже ой. ))
Здравствуйте, alex_public, Вы писали:
_>>>А что остальное (ну кроме поддержки в IDE — это отдельный вопрос)? WH>>Поиск имен, разрешение перегрузок, шаблоны итп. И отдельное веселье, когда оно всё сразу там начинаются всякие SFINAE и прочие радости. _>Шаблоны — это да, отдельная тема.
Без них это не С++. А на них и то что я перечислил ты потратишь десятки человеколет.
А сам парсер не проблема.
_>Ой, да пускай даже так, мне как-то вообще не принципиальны все эти мелочи. Вот если бы ты собрал бы этот проектик (не C++ парсер, а который генератор парсеров) и прогнал бы на какой-то своей тестовой грамматике с замером производительности (и сравнением с допустим твоими решениями, ANTLR и скажем тем же bizon'ом) — вот это было бы реально интересно почитать и потом обсудить. А вопрос активности разработки какого-то проектика, про который я только сегодня услышал мне вообще не интересен. )))
Ты вообще представляешь себе объём этой работы?
Одну и ту же грамматику этим парсерам не скормить. И я говорю не про изменение синтаксиса, хотя это само по себе большой объём работы, а про то что у них алгоритмы разные.
Тут придётся въезжать в особенности каждого алгоритма и трансформировать под него грамматику. Иначе тест будет нечестным.
При этом тестировать на маленькой грамматике бесполезно.
Короче это развлекалово ни на один месяц.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Так и что я "несу"-то? V>Покажешь хоть раз или нет?
Да уже много раз показывал.
V>Хуже-лучше определяется только по удовлетворению исходным требованиям. V>Если у них не стояла задача разработать ИДЕ для целевых языков программирования, то ты НЕ можешь сравнивать по таким требованиям.
NetBeans IDE parses C++ with ANTLR.
V>У них вообще не было таких ограничений — разработка пасеров только под ЯП. V>Они и над бинарными данными чудесно парсинг делают.
Если для разборы бинарного формата нужен генератор парсеров, то это означает что формат придумывал конченый неадекват.
V>У них стояла задача разработать учебную визуальную модель представления грамматик, по которой (модели) можно визуально отлаживаться в процессе проектирования этих грамматик. В этом плане их результаты лучше твоего, бо у тебя нет таких визуальных ср-в отладки грамматики, как в ANTLR:
ИДЕ с подсветкой, навигацией и автокомплитом почти есть. Сейчас Влад заканчивает бутстрап типизации. Как закончит так будет.
Графическое представление грамматики тупо не нужно. Там по сравнению с текстом нет никакой новой информации.
Визуализация автомата на маленьких грамматиках бесполезна. На больших как в твоём примере совершенно не читаема.
Да и автоматов в нитре нет. Так что и визуализировать нечего.
А то что действительно нужно у нас есть.
Но ты же даже не смотрел инструменты нитры.
V>А профайлер грамматики у тебя есть? V>Каким-либо образом можно узнать в Нитре, на сколько операций парсинга стало больше-меньше на тестовом примере после изменения грамматики?
Никто не просил. Вот и не сделали за ненадобностью.
V>Ну так не описывай восстановление в Бизоне и тоже всё будет автоматом.
Только работать при этом не будет.
V>Там вообще своё восстановление написать можно, бо кишки Бизона открыты.
Ты вообще понимаешь какой неадекват ты тут несёшь?
WH>>>>Это пользователь должен описывать правила восстановления руками. Ахринеть. WH>>>>1)Это куча мутной работы. V>>>Это примерно такая же работа, как в языке расширенных регулярных выражений отличать конечные правила от промежуточных. WH>>Что за бред опять? V>Что именно ты тут опять не понял?
Я понял, что ты не в состоянии держать контекст разговора.
Я вернул то что ты потёр. А теперь попробуй объяснить, как одно связано с другим?
V>Идём далее. Ты настаиваешь: V>2. У меня самый быстрый парсер. (С)
Я не говорил про самый быстрый. На простых грамматиках если задаться целью можно получить десятки, а если совсем упороться, то и сотни метров в секунду.
Я говорил про то что он просто быстрый.
Меньше 2-3 метров в секунду я не видел.
для сравнения
Я тут бьюсь с ANTLR4, который отдельные файлы с VHDL кодом разбирает ужасающе долго (со скоростью в 8К байт в секунду и даже меньше). Это, натурально, беда.
http://thesz.livejournal.com/1486500.html
V>Итого, ЛЮБОЙ самый первый вариант/макет ЛЮБОГО парсера будет подвергнут неадекватной обструкции сходу.
Адекватной. Ибо ты утверждаешь, что ничего быстрее GLR нет.
Вот поэтому тебе и нужно соответствовать.
Хотя на практике скорость работы GLR это 80 мегабайт в час.
V>Тебе надо было смотреть на GLR еще тогда, когда я именно что предлагал посмотреть на этот алгоритм как эффективную альтернативу Эрли.
Эрли в отличии от ГЛР парсер нисходящий. И поэтому отлично сочетается с основным парсером который тоже нисходящий. И если на основной парсер внимательно посмотреть, то он фактически ослабленный Эрли. И за счёт этого ослабления работает намного быстрее.
V>Потому что иначе получается так, что если на RSDN на блюдечке с голубой каёмочкой кто-то выложил реализацию Эрли, то ты её и асилил. V>А если тебе так же под нос не поставили — то уже и нет.
Ох. Ещё раз: Мой Эрли к тому Эрли отношения не имеет от слова совсем.
V>сейчас такая сумбурность/непоследовательность — это уже ой. ))
Ты последний кто может говорить про сумбурность и непоследовательность.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>Ой, да пускай даже так, мне как-то вообще не принципиальны все эти мелочи. Вот если бы ты собрал бы этот проектик (не C++ парсер, а который генератор парсеров) и прогнал бы на какой-то своей тестовой грамматике с замером производительности (и сравнением с допустим твоими решениями, ANTLR и скажем тем же bizon'ом) — вот это было бы реально интересно почитать и потом обсудить. А вопрос активности разработки какого-то проектика, про который я только сегодня услышал мне вообще не интересен. ))) WH>Ты вообще представляешь себе объём этой работы? WH>Одну и ту же грамматику этим парсерам не скормить. И я говорю не про изменение синтаксиса, хотя это само по себе большой объём работы, а про то что у них алгоритмы разные. WH>Тут придётся въезжать в особенности каждого алгоритма и трансформировать под него грамматику. Иначе тест будет нечестным. WH>При этом тестировать на маленькой грамматике бесполезно. WH>Короче это развлекалово ни на один месяц.
Вообще то с учётом вашего рода деятельности подобное должно было быть сделано давным давно (хотя бы для ANTLR и bison в сравнение с вашим решением). Чтобы потом тыкать всем в нос данные результаты. Почему такого нет (при этом в сочетание с твоими заявлениями о самом лучшем продукте в данной области) мне совершенно не понятно.
Ну а при наличие готовой развёрнутой инфраструктуры подобного тестирования добавить в него новый движок (типа всплывшего в данной дискуссии) по идее было бы не так уж сложно. Хотя я бы возможно ещё понял твоё не желание тратить своё время на подобную добавку, т.к. этот движок совсем не популярный (по сути это интересно только мне и то из любопытства, а не для чего-то реального). А вот отсутствия прямого сравнения с лидерами по индустрии понять уже не могу. )
Здравствуйте, WolfHound, Вы писали:
V>>Так и что я "несу"-то? V>>Покажешь хоть раз или нет? WH>Да уже много раз показывал.
Т.е. не можешь.
V>>Хуже-лучше определяется только по удовлетворению исходным требованиям. V>>Если у них не стояла задача разработать ИДЕ для целевых языков программирования, то ты НЕ можешь сравнивать по таким требованиям. WH>
WH>NetBeans IDE parses C++ with ANTLR.
NetBeans IDE изначально точно такой же учебный студенческий проект, как и ANTLR.
V>>Они и над бинарными данными чудесно парсинг делают. WH>Если для разборы бинарного формата нужен генератор парсеров, то это означает что формат придумывал конченый неадекват.
ASN.1 смотрел?
А какие профили кодирования смотрел?
V>>У них стояла задача разработать учебную визуальную модель представления грамматик, по которой (модели) можно визуально отлаживаться в процессе проектирования этих грамматик. В этом плане их результаты лучше твоего, бо у тебя нет таких визуальных ср-в отладки грамматики, как в ANTLR: WH>ИДЕ с подсветкой, навигацией и автокомплитом почти есть. Сейчас Влад заканчивает бутстрап типизации. Как закончит так будет. WH>Графическое представление грамматики тупо не нужно.
Наоборот. Единственная польза от подобных тулзов — это графическое представление грамматики и соответствующего AST.
Я никогда не пользовал ANTRL для генерации парсера, но несколько раз пользовал для отладки грамматики.
Ты не обратил разве внимания, что даже если нет всяких удобных графических ИДЕ с визуализацией, то тулкиты-парсеры под С++, например, порой имеют функциональность сбрасывать в картинку-граф "дамп" AST? Благо graphviz уже давно стандарт де-факто для таких вещей.
WH>Там по сравнению с текстом нет никакой новой информации.
Так у тебя дамп AST в виде текста? Или никакого дампа?
Ну и по самой грамматике — ес-но новой информации нет.
Есть другое представление имеющейся.
WH>А то что действительно нужно у нас есть. WH>Но ты же даже не смотрел инструменты нитры.
Мде...
Напомню, что ты общаешься на форуме программистов, которые каждый божий день работают в какой-нить среде разработки, т.е. прекрасно понимают как минимум целевую задачу Нитры. Т.е., прекрасно понимают сценарии, которые при этом происходят.
V>>А профайлер грамматики у тебя есть? V>>Каким-либо образом можно узнать в Нитре, на сколько операций парсинга стало больше-меньше на тестовом примере после изменения грамматики? WH>Никто не просил. Вот и не сделали за ненадобностью.
Ясно.
Узок их круг, страшно далеко они от народа. (С) Герцен.
Ок-ок, шутю. ))
Это всё не принципиально, ес-но.
Профайлер, свистелки и перделки спокойно прикручиваются при наличии большого круга пользователей и некоторого трафика запроса от них...
Дело в самом "ядре", сверху которого накручиваются потом примочки, верно?
Потому что чем дальше, тем меньше путей к отступлению.
Не переиграешь потом ничего в ядре, инерционность будет большая.
V>>Там вообще своё восстановление написать можно, бо кишки Бизона открыты. WH>Ты вообще понимаешь какой неадекват ты тут несёшь?
Да ну? Это я, значит, по обрывкам информации ориентируюсь и считаю, что владею ею? ))
WH>>>>>Это пользователь должен описывать правила восстановления руками. Ахринеть. WH>>>>>1)Это куча мутной работы. V>>>>Это примерно такая же работа, как в языке расширенных регулярных выражений отличать конечные правила от промежуточных. WH>>>Что за бред опять? V>>Что именно ты тут опять не понял? WH>Я понял, что ты не в состоянии держать контекст разговора.
Контекст тут один — формальные грамматики.
WH>Я вернул то что ты потёр. А теперь попробуй объяснить, как одно связано с другим?
Ты мне можешь один раз прямо ответить на прямой вопрос — ты в ВУЗ-е учился на программиста или нет?
Это уже не первая странность в этом и прошлых обсуждениях.
Мне иногда сложно сориентироваться, в каком виде что тебе давать...
Вещаю материалом 3-го курса:
Существует формальный язык описания регулярных выражений, у него есть три базовые операции:
— сцепление;
— дизьюнкция;
— повторение (0..oo);
В языке расширенного описания регулярных грамматик могут быть дополнительные операции:
— подстановка;
— повторение (1..oo, иногда M..N);
— отрицание символа;
— описание символа многократно (произойдёт автоматическая дизьюнкция);
— отрицание подстановки;
Я говорил о первом или последнем из расширений, когда в записях одних правил можно использовать другие.
Тут простые ограничения — одни и те же правила не должны одновременно расти справа или слева.
Т.е., при наличии по какому-то из правил рекурсии, она должна быть строго праволинейная или строго леволинейная (поэтому такие грамматики и зовут регулярными).
В такой системе часть правил может существовать сугубо для подстановки "общей части" для целевых правил, т.е. требуется отличать целевые правила от вспомогательных. В подстановке могут участвовать как целевые правила, так и не целевые.
В результирующем ДКА пометка конечного состояния (выхода) должна стоять только у целевых лексем, ес-но.
Т.е. в исходном описании грамматики необходимо как-то особо помечать целевые правила.
WH>для сравнения WH>
WH>Я тут бьюсь с ANTLR4, который отдельные файлы с VHDL кодом разбирает ужасающе долго (со скоростью в 8К байт в секунду и даже меньше). Это, натурально, беда.
1. Java.
2. Нисходящий.
3. Сама грамматика может быть кривая и косая.
Последнее — ключевое. На парсер надо возлагать как можно меньше работы. Это тот самый trade-off, который есть во всех компиляторах — что делается ручками, а что отдаём на откуп автомату.
V>>Итого, ЛЮБОЙ самый первый вариант/макет ЛЮБОГО парсера будет подвергнут неадекватной обструкции сходу. WH>Адекватной. Ибо ты утверждаешь, что ничего быстрее GLR нет.
Враки.
Или ссылку на такое утверждение в студию.
Я утверждал, что на однозначных цепочках получал скорость близкую к обычному LR-разбору.
У меня была задача найти заинтересованных пообсуждать найденные мною трюки буста производительности параллельного разбора.
Потому что вот я рядом в сообщении дал ссылки — нашел на днях описание похожих трюков, но на тот давний момент их тупо не было в сети.
Моё желание найти с кем обсудить было вполне объяснимым, не?
Да ты хотя бы с собой сравни, во что вы все форумы тогда превратили с ПЕГ/Пакратом.
В этом плане я выступал на многие порядки скромнее — сначала пытался найти заинтересованных в обсуждении конкретных алгоритмов.
В общем, для адекватного обсуждения требовалось желание собеседников "втыкать" в тему.
Вы с Владом втыкать отказались принципиально.
По причине "матан — для дебилов".
Вот есть серверное приложение. Вот одновременно сотни-тысячи клиентов гонят трафик на сервер, а он этот трафик ест прямо по ходу пьесы.
Средняя длина сообщения — в р-не десятков-сотен килобайт, иногда единицы метров.
Как сам думаешь, тысячи одновременно работающих парсеров Эрли выживут на таких длинах сообщений? ))
Понимаешь... Ты же вроде постоянно пытаешься претендовать на понимание предмета.
Поэтому, я обычно считаю, что коль дал тебе некую ВАЖНУЮ вводную — ну вот например про длинные неоднозначности и среднюю длину сообщений, и отсутствие роста "параллельности" с длиной цепочки, то тем самым дал исчерпывающую инфу о характере задачи. Хотел бы в ответ в этом месте видеть проблески понимания...
WH>Хотя на практике скорость работы GLR это 80 мегабайт в час.
Это бред бредовый.
Разбор естественных языков, да еще по таблицам синонимов.
Если ты принимаешь технические решения под влиянием столь чудовищной ангажированности — то ты их не принимаешь вовсе. Ты тыкаешь пальцем в небо.
V>>Тебе надо было смотреть на GLR еще тогда, когда я именно что предлагал посмотреть на этот алгоритм как эффективную альтернативу Эрли. WH>Эрли в отличии от ГЛР парсер нисходящий. И поэтому отлично сочетается с основным парсером который тоже нисходящий.
Восходящие парсеры отлично вызываются из нисходящих, особенно писаных методом рекурсивного спуска.
WH>И если на основной парсер внимательно посмотреть, то он фактически ослабленный Эрли. И за счёт этого ослабления работает намного быстрее.
Если ты про Пакрат и у вас сохранён именно алгоритм Пакрата — то не совсем. Пакрат запоминает удачные ветки разбора, Эрли все. Это принципиально. Держим это в уме и пытаемся ставить задачу.
* Вот я работаю в ИДЕ каждый божий рабочий день. Иногда в разных, иногда в принципиально разных.
* Когда от ИДЕ требуется наибольшее быстродействие парсинга? — верно, в моменты активного исправления исходника.
* насколько валиден исходник в такие моменты активного исправления? — я бы дал валидность в 10%-20% случаев исправлений, не выше. В остальное время исходник невалиден. Процесс набивки/перетасовки он такой, угу.
* выходит так, что необходимо добиться наилучшего быстродействия при невалидном исходнике и относительно достаточного при валидном.
А у тебя что? У тебя ровно наоборот — взят неадекватный алгоритм для невалидного исходника и шустрый для валидного.
Но этого мало — по твоим словам выходит так, что в случае ошибки парсинг запускается повторно. И это основной сценарий в процессе той самой активной набивки текста???
Скажем так. Мои замечания относительно твоего "поиграться с кодогенерацией" в алгоритмах масштабирования — это были цветочки. ))
А вот тут уже серьезные такие ягодки. Да это полный П.
Твоё самомнение сыграло с тобой совсем злую шутку... а уже и отступать некуда...
Вот неси теперь свой крест, выкручивайся.
Пока что всё выглядит так, что ты ДО СИХ ПОР не понял, почему я тогда настойчиво предлагал, таки, взглянуть вам на GLR.
ы-ы-ы
Хотя, кое-какие вещи ты уже начал понимать, смотрю...
А то надоел этот бесконечный парадокс бла-бла с тобой все годы, положа руку на...
V>>Потому что иначе получается так, что если на RSDN на блюдечке с голубой каёмочкой кто-то выложил реализацию Эрли, то ты её и асилил. V>>А если тебе так же под нос не поставили — то уже и нет. WH>Ох. Ещё раз: Мой Эрли к тому Эрли отношения не имеет от слова совсем.
Ага. Т.е., любой алгоритм, таки можно "допилить"? ))
У меня основная претензия к Эрли — что кол-во занимаемой памяти/степень параллельности начинает расти с ростом длины цепочки.
GLR этим не страдает вовсе. У него чем "шире" разбор, тем короче этот участок.
Для большинства ЯП я бы дал 99% цепочек однозначными (по крайней мере так можно описать грамматику).
И получал бы неоднозначности (или отсутствие разбора) только на ошибках.
V>>сейчас такая сумбурность/непоследовательность — это уже ой. )) WH>Ты последний кто может говорить про сумбурность и непоследовательность.
Слова "последний" и прочее лучше запрячь куда-нить туда, откуда ничего не отсвечивает.
Бо вы своей модерской безнаказанностью переходите границы сугубо уже бытового плана.
Это не тебе решать, в любом случае.
Форум публичный, ты сверкаешь нелогичностью и незамысловатой демагогией на весь мир.
Когда тебя на нелогичности ловишь, ты пытаешься замылить хамством, горлом и еще большей демагогией.
Чуть что — переход на личности. ))
А не работает это.
Никто тебе не верит и за клоуна считают.
Ты когда-то (до 2005-2006-го примерно) нарабатывал авторитет, потом быстро растерял.
Потому что ты стал ангажирован. Всегда.
Не объективен. Не уравновешен.
С тех пор ты лично поучаствовал в изгнании с форума полезных (намного полезнее тебя) коллег.
Любые твои технические решения, в которые мне доводилось вникать — практически всегда ошибочны и вызваны как пробелами по азам предметной области, так и по способностям к анализу/постановке технических задач и организации процесса разработки.
Даже в том обсуждении про БНФ ты не понял очевидной вещи — это возможности автоматической трансформации грамматик.
Я помню весь твой неадекват по этому поводу, угу.
Примерно как здесь.
Хотя задача реально востребована.
Просто ты НЕ понял даже самой задачи.
А людям для обработки нужно AST, которое удобное для банального понимания.
Но часто приходится подвергать грамматику факторизации/коррекции и получается уход от первоначальной идеи.
С AST по изменённой грамматике бывает работать неудобно.
Задача обратного отображения распаршенных данных на заданное изначально (до факторизации) AST — более чем востребована.
Мне так и не удалось донести тогда до тебя эту простую мысль.
Твои ответы — "задавай сразу алгоритм парсинга в ПЕГ" — демагогичны и показывали лишь дилетанство/некомпетентность.
В общем, ты часто не понимаешь и половины текста, который тебе говорят.
Вернее — и не хочешь понимать.
У тебя одна и та же отмазка, хотя тебе уже под сраку лет — "если я что-то не понимаю, то человек несет бред" (С).
Ничему тебя жизнь не научила.
В этом обсуждении я проржал, конечно. Много и часто.
Реально — это было забавно, спустя десятилетие наблюдать как ты начинаешь "втыкать" ну хоть в что-то из того, что я писал тебе, будучи намного младше, чем ты сейчас.
Сплошное ы-ы-ы, как грится.
Ладно. Как по мне, для сообщества IT ты человек уже потерянный.
Несерьезный в работе, несерьезный в обсуждении.
По верхам. Шапкозакидательство. Бесконечные отмазки и бесконечная демагогия.
Ты убил в себе специалиста. Давно. А так неплохо начинал лет 15 назад...
Как грится — вот вам влияние черт характера на успеваемость. ))
Кароч, в этом обсуждении могу похвалить — ты понял ОЧЕНЬ много.
В сравнении с прошлыми годами.
Выбесил неоднократно своим хамством, конечно, но оно того стоило.
Собсно, я хотел увидеть сам этот прогресс.
Потому что этот прогресс и есть самое забавное, будучи наложенным на твоё предыдущее напыщивание.
