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