Re[32]: Опциональные типы
От: WolfHound  
Дата: 18.03.17 11:27
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Наша песня хороша, начинай сначала?

Продолжаешь спорить с определениями? Ну-ну.

V>>>Ваша Нитра идёт на одну всего платформу, т.е. её потенциальный рынок тоже 2-3 построенных на ней ИДЕ.

WH>>Наша нитра уже сейчас может быть встроена в любую ИДЕ на винде, маке и линухе.
WH>>Ибо движок живёт в отдельном процессе и общается с ИДЕ по очень тонкому протоколу.
V>Пусть тогда в Сети где-то живет, какая уже тогда разница?
V>Даёшь ферму Nitra-сервисов? ))
Примерно всё что нужно уже готово.
Если будет спрос можно будет за несколько недель недостающий код написать.

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

V>Бинарные форматы, так же как и текстовые, могут иметь весьма развесистую грамматику.
Неадекват.
И бинарные форматы с развесистой грамматикой это и есть неадкват.

WH>>В крайнем случае можно использовать числа.

V>ЧТД. Прибили гвоздями к некоторой семантике бинарных операций.
Ты даже не попытался понять, что там происходит и делаешь выводы из того что тебе голоса напели.
Там полноценный "Top down operator precedence" Pratt, Vaughan.
А бинарные и унарные операторы только сахар, ибо используются примерно в 100% случаях.
А так там можно и что-то посложнее.
    precedence Choice:
    | Choice                  = LeftRule=RegexExpression ^ Choice sm RightRules=("|" RegexExpression ^ Choice)+
    
    precedence Sequence:
    | Sequence                = LeftRule=RegexExpression ^ Sequence sm RightRules=(RegexExpression ^ Sequence)+

Вот так описываются N'арные операторы.
В данном случае оператор пробел имеет больший приоритет чем оператор |.

V>>>И не надо мне опять про набивший оскомину ПЕГ, где приоритет задаётся явно через "правильную" очередность описания правил.

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

V>Для сторонних читателей мне малость лень расписывать, но "честность" выбора резко развязывает руки в деле описания грамматики.

Да не особо на самом деле.
Главная проблема приоритетного выбора в случае с нитрой это невозможность объединения грамматик.

WH>>Я спрашиваю нахрена мне графическое представление грамматики?

V>Тебе не надо, мне надо.
V>Я большие массивы информации лучше читаю в виде карт-схем.
Может тебе и код на С в виде диаграммы нужно?

WH>>>>Что тебе даст стрелка, идущая мимо expression по сравнению со знаком "?" стоящим после expression?

V>>>Покажет, правильно ли я поставил закрывающие скобки.
WH>>
V>ЧТД. Нечего ответить.
V>Речь о скобке в исходном описании грамматики, а не во входных данных для разбора.
А что вообще на этот бред ответить можно?
Это настолько высосано из пальца что дальше просто некуда.

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

Я утверждаю немного другое: Все опубликованные тесты GLR говорят о том, что он тормозит.
Ты можешь создать тест, который покажешь, что GLR крут.
Тогда ты будешь молодцом. А до тех пор будешь треплом.

V>Вот еще чуток копнул, вижу алгоритм NR GRL.

V>Вот данные по грамматике языка С в кол-ве операций обхода для некоего тестового примера:
Мне не нужны попугаи.
Мне нужны корректные тесты производительности, которые я могу запустить.
А то мой парсер даёт разброс на грамматике C# от 3 до 100 метров в секунду на разных файлах.
Так что подбором данных можно очень много накрутить.

V>>>Ну так в другой раз переспроси, если некая терминология не понятна, а не накидывайся сходу.

WH>>Ну так я и спрашиваю. Как ручное описание алгоритма восстановления (что само по себе дикий неадекват) относится к целевым правилам в лексере?
V>Ну ясно. Не понял и не понял даже расписанное на пальцах.
V>Соображалка с возрастом ухудшается?
V>И это говорит тот, кто постоянно обвиняет в непонимании других?
Ну так ты объясни. Или только со своими голосами договориться можешь?

V>>>Считай, что ты таким образом помечаешь правила, до которых имеет смысл восстановиться.

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

V>>>Ты же взял Эрли, а там всё было еще печальнее в тестах?

WH>>Ты меня совсем не слушаешь. Эрли работает на 1% кода и только в случае если код сломан.
V>1. У меня в процессе активной набивки код практически всегда сломан.
Ещё раз. Именно в этом случае Эрли работает на 1% кода.
Когда код без ошибок Эрли вообще не работает.

V>2. Всё равно выбор Эрли из других обобщённых не обоснован.

Ты не можешь судить. Ибо совершенно не понимаешь, что там происходит.

V>А есть ли в коде парсера по ДКА, построенному для LL(1) явная операция "предпросмотра"?

V>Нет? А в самом исходном алгориме есть.
V>Как так?
Вот кусок кода который сгенерировал Coco/R который является генератором LL(1) парсеров.
Код вида if (la.kind == 14) и есть предпросмотр.
    void RelOp(out Op op) {
        op = Op.EQU; 
        if (la.kind == 14) {
            Get();
        } else if (la.kind == 15) {
            Get();
            op = Op.LSS; 
        } else if (la.kind == 16) {
            Get();
            op = Op.GTR; 
        } else SynErr(30);
    }

    void Factor(out int type) {
        int n; Obj obj; string name; 
        type = undef; 
        if (la.kind == 1) {
            Ident(out name);
            obj = tab.Find(name); type = obj.type;
            if (obj.kind == var) {
            if (obj.level == 0) gen.Emit(Op.LOADG, obj.adr);
            else gen.Emit(Op.LOAD, obj.adr);
                         } else SemErr("variable expected"); 
        } else if (la.kind == 2) {
            Get();
            n = Convert.ToInt32(t.val); 
            gen.Emit(Op.CONST, n); type = integer; 
        } else if (la.kind == 4) {
            Get();
            Factor(out type);
            if (type != integer) {
             SemErr("integer type expected"); type = integer;
            }
            gen.Emit(Op.NEG); 
        } else if (la.kind == 5) {
            Get();
            gen.Emit(Op.CONST, 1); type = boolean; 
        } else if (la.kind == 6) {
            Get();
            gen.Emit(Op.CONST, 0); type = boolean; 
        } else SynErr(31);
    }

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