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

V>>Очевидно так, что для некоторых сценариев трюка эмуляции ЗТ достаточно.
V>>В упомянутых звуковой предметной области пачки отсчетов не просто конечного размера, а строго по некоей сетке:
V>>40 байт, 80, 120, 160, 240, 320.
WH>1)Это не имеет никакого отношения к зависимым типам.
WH>Просто по определению зависимых типов.

Что "это"?
Можно прервать поток сознания и формулировать по-русски?


WH>2)Ты говоришь про конечный (и очень маленький) набор вариантов, а я говорю про БЕСКОНЕЧНЫЙ.

Мама мия...
Зависимые типы могут работать даже над bool, где всего два значения.

В общем, если ты считаешь, что определение "зависимые типы" относятся только к неким мифическим "бесконечным" мн-вам допустимых значений типов, то ты НЕ понимаешь, что такое зависимые типы. Или неверно себе представляешь эту технологию.
Иди почитай Пирса или HoTT.


V>>Общаешься с коллегами забыв проснуться.
WH>Отсутствие головного мозга демонстрируешь тут исключительно ты.
WH>Даже определение зависимых типов запомнить не в состоянии.

Да, да. Ты только что "блеснул" в очередной раз.
Опять прёт вот эта твоя поверхностность...

Вот это в тебе всегда раздражало, что сосредоточившись — ты что-то можешь. ))
Но в 99% случаев ты рассеян, увы.


WH>Да даже несоизмеримо более простой альфабленд пикселей с альфаканалом для тебя запредельно сложен.

Твой пример с альфаблендом был высмеян не за ошибочность, а за элементарщину, не соответствующую тому, как ты с этой элементарщиной носился, как с писанной торбой.

Собсно, эти замашки необъяснимы.

Точно так же тебя потом укусил ПЕГ, что ты на коллег натурально бросался, так над тобой уже откровенно глумились с этим ПЕГ...

Не видишь себя со стороны. Не выдержан. Нелеп. Разговариваешь с голосами в голове, а не с реальными оппонентами. Т.е. склонен к нечистоплотности в спорах, активно приписывая оппонентам "удобную для разбивания" точку зрения. Не в состоянии принять аргументы оппонента как они есть без того, чтобы не "допилить" их до удобного для "опровержения" варианта. Слабак, кароч.


WH>Да ещё трепло, ибо генератор GLR парсеров который работает быстрее лексера ты так и не показал.

ЧТД. Трепло тут ты. Говорилось, дословно:

со сравнимой с лексером скоростью на большинстве цепочек.

И никто тебе не обещал полноценный генератор парсеров.
Наоборот, я ПРЕДЛАГАЛ тебе, коль уже ты делаешь "универсальный генератор" обратить внимание на GLR — отсюда мы и зацепились, Остапа опять понесло. ))

А так-то у меня есть настраиваемый парсер, используется уже давно.
Парсер настраивается по специфическим схемам док-в EDI.
Тело парсера писано ручками. Таблица автомата генерится в рантайм по поданной схеме.
Работает в одном из нагруженных серваков сертификации EDI-документов.


WH>Ибо если бы такие существовали, то я бы GLR и использовал.

Ага, ветер дует от того, что деревья качаются.

Подсказка №1: GRL/LALR существуют во всех компиляторах языков, где требуется перемалывать БОЛЬШИЕ объемы исходников.
Подсказка №2: дотнет и немерле — это НЕБОЛЬШИЕ объемы исходников, скорее микроскопические.

В общем, ты обитаешь в мире небольшой нагрузки на парсеры и отсюда у тебя искажённые представления обо всём.

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

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

И вот даже в этом обсуждении — сходу наговорил глупостей, но окружающим непременно раздаешь "бред", "ты бредишь" и т.д.
Ничего не меняется... ))


WH>Но в реальной реальности, а не твоём воображении у GLR огромная константа

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

Или можно вместо таблицы реализовать на goto, но здесь требуется более сложный генератор, чем построитель таблицы переходов.


WH>которая тормозит даже когда GLR не улетает в O(N^3). Это подтверждают ВСЕ работы по GLR которые я видел.

При том, что программист с твоим опытом мог бы потратить пару дней и проверить самому, не?
Тем более, что я давал конкретные координаты сценариев, когда GLR рвет всех и вся как тузик грелку:

входные цепочки большой длины, но низкой "глубины" вложенности.

Любой алгоритм с откатами/мемоизациями просто не работает на таких данных.
Вернее, работает, но это ж-па полная.

Смотри.
Пусть даже для некоторой цепочки GLR протягивает одновременно/параллельно пару цепочек разбора по таким данным, т.е. работает на каком-то участке чуть медленней единичного лексера, но (!!!) зато потом не надо будет откатываться на мегабайты символов назад. Никакая мемоизация и никакой откат в этих условиях банально не живут.

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

И, по моим исследованиям, "широкие" параллельные цепочки возникают редко.
Вернее, там такая зависимость — чем больше "параллельности", тем короче этот участок.
В языках программирования аналогично — неоднозначные места обычно очень "коротки".

А "совсем длинными" бывали цепочки, на которых шло по 2 от силы ветки разбора. И всего лишь однажды наблюдалось устойчивых 3 ветки на примерно 20-25% общей длины цепочки. В этом смысле современные языки программирования намного более однозначны, в сравнении со схемами док-в из области EDI.

А что касается константности — то это вопрос управления ресурсами. В GLR необходимо уметь оперативно порождать конкурирующие ветки разбора корнем от текущей и так же оперативно убивать отмершие, т.е. текущей может стать одна из новых конкурирующих.

Тут даже представление нетерминалов, получаемых от лексера, и то важно. ))
Я только на этом представлении умудрился скорость чисто парсинга поднять примерно вдвое. Т.е., включение парсера сверху лексера давало, скажем +20% ко времени работы "чистого лексера" (без парсера), а после вылизывания представления нетерминалов — всего 10% от чистого лексера. (Т.е. подключили к лексеру полноценный парсер, скорость потребления потока упала на 20% и 10% соответственно).

Т.е. эта константа не теоретическая ни разу, а зависит сугубо от реализации.
И так по каждому моменту этой "константы" — оно допиливается почти до скорости работы чистого лексера.

Далее.
Так же утверждалось, что он есть ВСЕ контекстно-свободные грамматики.
Т.е. пусть у нас даже будет сильно неоднозначная грамматика, данная сверху.
Однозначно её распарсить можно лишь GLR (или любым другим параллельным алгоритмом, не боящимся рекурсий, типа Эрли).

Т.е. вот тебе еще один сценарий, где GLR мог бы помочь.

К тому же, GLR — это алгоритм разбора, а не способ описания грамматики.