Re[28]: Опциональные типы
От: WolfHound  
Дата: 13.03.17 10:50
Оценка:
Здравствуйте, vdimas, Вы писали:

V>>>Так и что я "несу"-то?

V>>>Покажешь хоть раз или нет?
WH>>Да уже много раз показывал.
V>Т.е. не можешь.
Одних ЗТ в С++ более чем достаточно.

V>NetBeans IDE изначально точно такой же учебный студенческий проект, как и ANTLR.

Тем не менее ANTLR для IDE использовать пытаются.

V>ASN.1 смотрел?

V>А какие профили кодирования смотрел?
Ты собрался ASN.1 парсить при помощи ANTLR?
И после этого ты тут про адекватность говоришь?

WH>>Графическое представление грамматики тупо не нужно.

V>Наоборот. Единственная польза от подобных тулзов — это графическое представление грамматики и соответствующего AST.
Так в чём польза то?
Вот смотрим на твой первый скриншот.
Там есть визуализация iteration_statement.
И ровно то же самое написано в коде.
Ну и смысл?

WH>>Там по сравнению с текстом нет никакой новой информации.

V>Так у тебя дамп AST в виде текста? Или никакого дампа?
У меня есть дерево с двусторонней навигацией между АСТ и текстом из которого этот АСТ получен.

V>Ну и по самой грамматике — ес-но новой информации нет.

V>Есть другое представление имеющейся.
Зачем?
Что тебе даст стрелка, идущая мимо expression по сравнению со знаком "?" стоящим после expression?

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

Не похоже.

V>>>А профайлер грамматики у тебя есть?

V>>>Каким-либо образом можно узнать в Нитре, на сколько операций парсинга стало больше-меньше на тестовом примере после изменения грамматики?
WH>>Никто не просил. Вот и не сделали за ненадобностью.
V>Ясно.
V>Узок их круг, страшно далеко они от народа. (С) Герцен.
Парсер нитры очень предсказуем в отличии от всяких ANTLR'ов у которых производительность от каждого чиха скачет.

V>Дело в самом "ядре", сверху которого накручиваются потом примочки, верно?

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

V>>>Там вообще своё восстановление написать можно, бо кишки Бизона открыты.

WH>>Ты вообще понимаешь какой неадекват ты тут несёшь?
V>Да ну? Это я, значит, по обрывкам информации ориентируюсь и считаю, что владею ею? ))
1)Именно ты.
2)Как эти две твои фразы соотносятся между собой не ясно.


WH>>>>>>Это пользователь должен описывать правила восстановления руками. Ахринеть.

WH>>>>>>1)Это куча мутной работы.
V>>>>>Это примерно такая же работа, как в языке расширенных регулярных выражений отличать конечные правила от промежуточных.
WH>>>>Что за бред опять?
V>>>Что именно ты тут опять не понял?
WH>>Я понял, что ты не в состоянии держать контекст разговора.
V>Контекст тут один — формальные грамматики.
После этого про адекватность больше не говори.

WH>>Я вернул то что ты потёр. А теперь попробуй объяснить, как одно связано с другим?

V>Ты мне можешь один раз прямо ответить на прямой вопрос — ты в ВУЗ-е учился на программиста или нет?
Успокойся. Про регулярные выражения я знаю намного больше чем ты.

V>В результирующем ДКА пометка конечного состояния (выхода) должна стоять только у целевых лексем, ес-но.

V>Т.е. в исходном описании грамматики необходимо как-то особо помечать целевые правила.
1)В нитре всё прекрасно работает без всяких пометок
    regex EscChar                   = '\\' | '/' | 'b' | 'f' | 'n' | 'r'| 't' | 'u' HexDigit HexDigit HexDigit HexDigit
    {
      regex HexDigit                  = ['0'..'9', 'a'..'f', 'A'..'F'];
    }

      regex Quote   = '\"';
      regex Esc     = '\\' (Quote | EscChar);
      regex Escs    = Esc+;
      regex NotEscs = Any+ - (Any* (Quote | '\\' | NewLine) Any*);

Обрати внимание на NotEscs. Там из множества непустых строк вычитаются все строки, которые содержат Quote | '\\' | NewLine.
Вот такое вот вычитание одного бесконечного множества из другого.
И это просто частный случай более общей операции.
    public Xor(fsm1 : FSM, fsm2 : FSM) : FSM
    {
      Product([fsm1, fsm2], fun(([ok1, ok2])) { set => set.Contains(ok1) ^ set.Contains(ok2) })
    }

    public Sub(fsm1 : FSM, fsm2 : FSM) : FSM
    {
      Product([fsm1, fsm2], fun(([ok, fail])) { set => set.Contains(ok) && !set.Contains(fail) })
    }

    public Product(fsms : list[FSM], makeIsOkState : list[int] -> (Set[int] -> bool)) : FSM
    {
      def (result, resultStart) = FSM().NewStartState();
      def (result, resultOkStates) = fsms.Fold((result, []), (fsm, (result, resultOkStates)) =>
      {
        def (result, fsmStart, fsmOkStates) = result.IncludeFSM(fsm);
        def (result, fsmOkState) = result.NewState();
        def result = result.AddTransition(Transition.Epsilon(resultStart, fsmStart));
        def result = fsmOkStates.Fold(result, (okState, result) => result.AddTransition(Transition.Epsilon(okState, fsmOkState)));
        (result, fsmOkState :: resultOkStates);
      });
      MakeDeterministic(result, makeIsOkState(resultOkStates.Reverse()))
    }


2)Как это связано с ручным описанием восстановления не ясно.

V>В общем, для адекватного обсуждения требовалось желание собеседников "втыкать" в тему.

Мы предварительно посмотрели тесты производительности. И там всё было очень печально.

WH>>Хотя на практике скорость работы GLR это 80 мегабайт в час.

V>Это бред бредовый.
V>Разбор естественных языков, да еще по таблицам синонимов.
V>Если ты принимаешь технические решения под влиянием столь чудовищной ангажированности — то ты их не принимаешь вовсе. Ты тыкаешь пальцем в небо.
Да все тесты ГЛР имеют похожие цифры.

WH>>И если на основной парсер внимательно посмотреть, то он фактически ослабленный Эрли. И за счёт этого ослабления работает намного быстрее.

V>Если ты про Пакрат и у вас сохранён именно алгоритм Пакрата — то не совсем.
Естественно не совсем. Я же сказал ослабленный.

V>Пакрат запоминает удачные ветки разбора, Эрли все. Это принципиально. Держим это в уме и пытаемся ставить задачу.

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

V>А у тебя что? У тебя ровно наоборот — взят неадекватный алгоритм для невалидного исходника и шустрый для валидного.

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

V>Но этого мало — по твоим словам выходит так, что в случае ошибки парсинг запускается повторно. И это основной сценарий в процессе той самой активной набивки текста???

Так всё же запомнено.
Так что ничего из того что уже отпарсено не перепарсивается.
Нужно только несколько раз в таблицу мемоизации заглянуть.
Ты понимаешь, что с таким захлёбом о наносекундах говоришь? При том что время реакции человека 100 миллисекунд.

V>У меня основная претензия к Эрли — что кол-во занимаемой памяти/степень параллельности начинает расти с ростом длины цепочки.

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

V>Любые твои технические решения, в которые мне доводилось вникать — практически всегда ошибочны и вызваны как пробелами по азам предметной области, так и по способностям к анализу/постановке технических задач и организации процесса разработки.

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

V>Даже в том обсуждении про БНФ ты не понял очевидной вещи — это возможности автоматической трансформации грамматик.

Не нужно. Просто не нужно если алгоритм и так работает.

V>А людям для обработки нужно AST, которое удобное для банального понимания.

V>Но часто приходится подвергать грамматику факторизации/коррекции и получается уход от первоначальной идеи.
V>С AST по изменённой грамматике бывает работать неудобно.
А в случае с нитрой не приходится.
Прикинь.
Ты описываешь грамматику так как удобно, и она просто работает.

V>Кароч, в этом обсуждении могу похвалить — ты понял ОЧЕНЬ много.

Я тут ничего кроме банальностей, которые давно знал не сказал.
А вот ты так до сих пор ничего и не понял.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.