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

V>>Потому что ты нихрена не понимаешь собеседника опять, как тогда с зависимыми типами. ))
WH>Ты до сих пор считаешь, что в С++ есть зависимые типы?

Я до сих пор считаю что ты поверхностен.

Ну и твой вопрос не имеет смысла, потому что мы уже разобрали недавно по косточкам два момента:
— уже было доказано и показано, что шаблоны С++ времени компиляции представляют из себя Тьюринг-полный ФП-язык с зависимыми типами;
— в случае покрытия специализациями шаблонов (можно частичными) ВСЕХ диапазонов термов, поведение программы а рантайм не отличается от аналогичной программы в зависимых типах; мы подробно разбирали "строго-типизированные ордера", где матрица состояний ордера была перенесена из данных в систему типов; в этом случае компилятор сам нагенерил всевозможные варианты, соответствующие использованными де-факто "клетками" такой матрицы (некоторые клетки могут быть невалидными, под них ничего не генерится); ну а трюк со "схлопыванием" шаблонного кода затем уменьшил повторы в бинарнике. Ву а ля. ))


WH>Кстати GLR парсер который работает быстрее лексера я до сих пор жду.

Обещано было "со сравнимой с лексером скоростью на большинстве цепочек".
Это как бэ, сама суть LR-разбора на цепочках без отката (программа не содержит ошибок, например), потому что обычный лексер — это LR(0).
Я тебе это уже писал, просто ты в этом вопросе плаваешь. Вернее, такова твоя принципиальная позиция — "даже не хочу знать". ))

Т.е., как работает автоматный лексер по "жадному" алгоритму ты интуитивно понимаешь, ОК, но как этот алгоритм соотносится с LR(k) — понятия не имеешь.

И зачем ждать, когда уже всё есть? Парсеры в промышленных компиляторах С++ — все поголовно GLR или модифицированный LALR.
Никакие существующие в природе парсеры не работают быстрее.

Собсно, из-за необходимости на каждый CPP-файл перемалывать многие мегабайты H-файлов, парсинг в С++-компиляторах вылизан по самое небалуй. Если ты предложишь нечто кардинально быстрее работающее (хотя бы на 30%-50%) — можешь смело номинироваться на "Нобелевку по Информатике" (премию Тьюринга).

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

V>>Потому что ты нихрена не понимаешь собеседника опять, как тогда с зависимыми типами. ))
WH>Ты до сих пор считаешь, что в С++ есть зависимые типы?

Я до сих пор считаю что ты поверхностен.

Ну и твой вопрос не имеет смысла, потому что мы уже разобрали недавно по косточкам два момента:
— уже было доказано и показано, что шаблоны С++ времени компиляции представляют из себя Тьюринг-полный ФП-язык с зависимыми типами;
— в случае покрытия специализациями шаблонов (можно частичными) ВСЕХ диапазонов термов, поведение программы в рантайм не отличается от аналогичной программы в зависимых типах; мы подробно разбирали "строго-типизированные ордера", где матрица состояний ордера была перенесена из данных в систему типов; в этом случае компилятор сам нагенерил всевозможные варианты, соответствующие использованными де-факто "клетками" такой матрицы (некоторые клетки могут быть невалидными, под них ничего не генерится); ну а трюк со "схлопыванием" шаблонного кода затем уменьшил повторы в бинарнике. Ву а ля. ))


WH>Кстати GLR парсер который работает быстрее лексера я до сих пор жду.

Обещано было "со сравнимой с лексером скоростью на большинстве цепочек".
Это как бэ, сама суть LR-разбора на цепочках без отката (программа не содержит ошибок, например), потому что обычный лексер — это LR(0).
Я тебе это уже писал, просто ты в этом вопросе плаваешь. Вернее, такова твоя принципиальная позиция — "даже не хочу знать". ))

Т.е., как работает автоматный лексер по "жадному" алгоритму ты интуитивно понимаешь, ОК, но как этот алгоритм соотносится с LR(k) — понятия не имеешь.

И зачем ждать, когда уже всё есть? Парсеры в промышленных компиляторах С++ — все поголовно GLR или модифицированный LALR.
Никакие существующие в природе парсеры не работают быстрее.

Собсно, из-за необходимости на каждый CPP-файл перемалывать многие мегабайты H-файлов, парсинг в С++-компиляторах вылизан по самое небалуй. Если ты предложишь нечто кардинально быстрее работающее (хотя бы на 30%-50%) — можешь смело номинироваться на "Нобелевку по Информатике" (премию Тьюринга).