Информация об изменениях

Сообщение Re[33]: Опциональные типы от 09.03.2017 2:07

Изменено 10.03.2017 10:06 vdimas

Re[33]: Опциональные типы
Здравствуйте, WolfHound, Вы писали:

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

V>>Ты никуда его не возвращаешь, ты оперируешь им исключительно в том же блоке кода, в котором прочел что-то из входа — я вижу чтение из входа прямо в теле main. Для решения задачи все операции чтения должны быть внутри некой ф-ии, которая вызывается из main, внутри себя читает вектор и возвращает его вызывающему коду. Иначе слил.
WH>1)Это тебе голоса в голове напели.

Т.е. ты слил?


WH>2)Так ты повторишь этот код на хаскеле или таки опять расписался в том, что трепло?


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


V>>Как сформулируешь очередную "задачку, с которой справятся только ЗТ", так приходи.

WH>Так я уже сформулировал. То, что ты не в состоянии написать код это подтверждает.

Пока что я вижу, что ты не в состоянии написать код, который вернет вектор из некоей ф-ии, внутри которой сам вектор будет прочитан динамически. Мне требовалось именно это и ты это прекрасно понял.
Потому что твоя постановка вопроса вот тут:

Попробуй вернуть этот вектор в функцию main таким образом, чтобы тип сохранился.

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

В реальной жизни трюка с вызовом полиморфного колбэка (стиль CPS) — достаточно, особенно если этот трюк поддерживается синтаксисом языка: аппликациями или монадами. Остальное — это лирика и верчение ужей на сковородах.


WH>>>2)Ты даже упрощённый вариант показать не можешь. Ибо трепло.

V>>Ибо прикольно быть модером и хамить, верно?
WH>Ну так код то будет или как всегда трепло?

Моё "код в студию" равносилен утверждению, что подобное невозможно.
И, судя по тому, что ты НЕ в состоянии показать обещанное — я опять прав, а ты опять слил.

Вот тут у тебя фигня полная написана, а не обещанное:
http://www.rsdn.org/forum/philosophy/6716357.1

Итого — трепло.


V>>По этой теме уже всё с тобой ясно — ты не в состоянии показать только что тобой же обещанное.

WH>Ясно что ты не можешь написать десяток строк кода.

Да нечего там писать.
Обещанное тобой не имеет решения.
По крайней мере на Idris.
В общем, ты опять показал своё плохое понимание зависимых типов.


V>>Он как раз регулярно тут хамит окружающим.

V>>Намного-намного реже тебя, но, таки, регулярно.
WH>Окружающим это тебе?

Я тут участвую далеко не во всех темах, больше читаю и то, менее 10%.
У меня довольно-таки узкий круг тем, по которым я регулярно отписываюсь.

Это ж ты у нас везде поспел, как же. ))
Помнишь свою фишку про "capability"?
Ты ведь так и НЕ понял того трюка, что самое смешное. ))
Там прикол в том, что и сами авторы тоже не поняли суть собственного трюка. Такие же дилетанты, фиг ле.

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

Этот трюк легко выражается через создание семейств "несовместимых" типов-контейнеров, хранящих внутри себя "совместимые" типы по-значению.
Вот и всё кино.
Остальное — синтаксический сахар, не более.

В данном случае они назвали этот синтаксический сахар capability и поэтому вылетели с красной карточкой за границы теории типов (за любую из теорий типов), поэтому, следующую игру пропускают. ))

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

Ты не смог ни первого, ни второго.
Твои объяснения были сумбурными, непоследовательными и нелогичными.
Мне пришлось читать про ту хрень самостоятельно и долго над авторами и тобой ржать. ))


V>>Я такой подход хорошо знаю — нахвататься по верхам и тешить своё ЧСВ за счет окружающих.

WH>Это про тебя.

Ага, это я, значит, не мог 8 лет сообразить, что мне говорят? ))
Это я, значит, не отличаю compile time от runtime?
Или это был некто WolfHound? ))
Кончай ломать комедию. Ты откровенно тормозил огромное кол-во лет. Чудовищное кол-во лет по меркам IT.


V>>Стоило только чуть ноготком подцепить и выяснилось, что он сам в этой теории изрядно плавает.

WH>Да ты её вообще не знаешь.
WH>Путаешь рода типов и классы типов. Да ещё сорта типов придумал.

Я как раз не путаю, я как раз говорю — где у нас терминология конкретного языка программирования, а где общая теория типов (какой-то из теорий, бо их больше одной).
А вот ты путаешь терминологию отовсюду.
В общей теории типов есть только одна иерархия: терм, тип, мн-во типов.
Это всё.
Остальное — конструкторы типов и ф-ий разной замысловатости: П-функции (полиморфные), П-типы (зависимые), E-типы (зависимые от литералов) и т.д.

А ты там херню писать изволил.
Потому что рода и классы типов — это терминология сугубо Хаскеля.
И тебе многократно это говорилось, но ты спишь, пока в форум пишешь, вестимо.
Невнимателен, не собран.

Далее.
Под "сортами" типов многие авторы подразумевают НЕСОВМЕСТИМЫЕ м/у собой типы и прямо об этом говорят.
Примеры сортов типов я тебе приводил.
Кароч, у тебя дикая каша в голове из обрывков информации.


V>>Как и ты, который НЕ понимает, что есть "сорта типов". )))

WH>Только в твоей голове. В теории типов их нет.

Ага, всё-таки почитал кое-что?
Молодец!
Вот в другой раз сначала читай, потом возражай.


V>>Я ведь именно тебе (единственному из этих 3.5 человек) МНОГОКРАТНО говорил, что конкретно у тебя проблема в том, что ты зачастую и не хочешь знать. Лично мне со стороны даже где-то обидно за незнакомого мне человека — вроде голова твоя соображать умеет (что приятная редкость, прямо скажем), а вроде часто по верхам, кусочно гладко, не систематично и вообще... Жаль, просто жаль... Потому что у других, кто тут регулярно психует, скажем прямо, проблемы совсем другого плана, я бы даже сказал — местами совершенно непреодолимого плана. ))

WH>Проблемы непреодолимого плана тут только у тебя.
WH>Настолько упёртого невежду я ещё не видел.

Т.е. это я 8 лет упирался по элементарным вопросам? ))


V>>Вы ж разогнали всех более-менее интересных собеседников с этого сайта в разные годы.

WH>Это таких же безграмотных, как и ты?

В этом споре в безграмотных ходишь ты и еще долго будешь.

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

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


V>>- на шаблонах это всё заняло бы примерно столько же времени, сколько потребовалось бы лишь для того, чтобы закодировать предметную область для кодогенерации (и это еще БЕЗ самой генерации).

WH>И очень хорошо зная возможности шаблонов я выбрал внешнюю кодогенерация, ибо знал что шаблоны на этой задаче сдохнут.

На приведенной формуле они не сдохнут.


WH>Ты конечно можешь легко опровергнуть мои слова показав решение на шаблонах.


Показать решение должен был ТЫ, коль утверждал, что получил решение ЛУЧШЕ.
Потому что вопрос стоял так — лучше чем "что"? ))
Сравнение где?
В общем, вменяемого ответа не было, детсад.
Оставалось глумиться.

Решений может быть мильон, сходу накидал, даже не компиллировал, но это пофик, общая идея понятна:
typedef float f;

struct Color8Bit_Traits
{
  typedef uint8 C;

  static C roundC(f value) {
     return round(value)
  }
};

struct Alpha8Bit_Traits
{
  typedef uint8 A;

  static A fromF(f value) {
     return floor(value * 255.5f);
  }

  static f toF(A value) {
     return value / 255f;
  }
};

struct RGBA8_Traits_Base : Color8Bit_Traits, Alpha8Bit_Traits {
  typedef uint32 pixel;

  static C getR(pixel value) { return value & 0xFF; } 
  static C getG(pixel value) { return (value >> 8) & 0xFF; } 
  static C getB(pixel value) { return (value >> 16)& 0xFF; } 
  static f getA(pixel value) { return value >> 24; } 
  static f getAF(pixel value){ return toF(getA(value)); } 
  
  static pixel make(C r, C g, C b, A a) {
    return makeUInt32(r, g, b, a);
  }

  static C mixC(C u1, f a1, C u2, f a2) {
      roundC(u1*a1 + u2*a2);
  }
};

template<typename Traits>
struct RGBA_Traits : Traits {
  static pixel blend(pixel p1, pixel p2, f mix) {
    f a1 = getAF(p1) * mix;
    f a2 = getAF(p2) * (1 - mix);

    C r = mixC(getR(p1), a1, getR(p2), a2);
    C g = mixC(getG(p1), a1, getG(p2), a2);
    C b = mixC(getB(p1), a1, getB(p2), a2);
    C a = mixC(getA(p1), a1, getA(p2), a2);

    return make(r, g, b, a);
  } 
};

typedef RGBA_Traits<RGBA8_Traits_Base> RGBA8_Traits;
// и т.д.
// ...


Итого, алгоритм для ВСЕГО rgba-семейства содержится в некоем RGBA_Traits.
Аналогично надо описать алгоритмы для hsl, cmyk и т.д.
По-сути, получаются ортогональные координаты:
— способы кодирования цвета;
— битовая упаковка.

Сложности тут надуманные.
Я НЕ верю, что ты бы не решил эту задачу.


WH>Но как мы уже выяснили код ты писать не умеешь.


Голоса в голове...


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

WH>Очень даже причём. Вы же пытались гнать бред про то что там всё можно обобщить. Я показал почему нельзя обобщить.

Нихрена ты не показал.
Нужно было или дать сравнение двух подходов или ничего не утверждать, а тихо слиться.
Потому что иначе твоё решение выглядит НЕОБОСНОВАННЫМ.


WH>>>И суперпупермегабыстрый GLR я до сих пор жду. Ни LR(0) или что там тебе ещё голоса в голове напоют, а полноценный GLR.

V>>Я никому не обещал никакой код, с чего ты взял-то?
WH>С того что ты утверждаешь то что противоречит всем работам по GLR.

Брехня опять.
Я раз 10 повторил сценарии/условия, где GLR себя хорошо показал.
Вместо разбора сценариев и озадачиванием — а ПОЧЕМУ так происходит с этим алгоритмом на этих сценариях, ты потребовал некий код.
Т.е., думать ты отказался сходу.
ОК.
Но ты опять этим забавен.


WH>А значит тебе нужно либо доказать свои слова кодом


Пока что всё тобой озвученное лишь означает, что мне надо проделать некую немалую работу по выдиранию алгоритма из боевого проекта, и всё только для того, чтобы заинтересовать с вероятностью 0.3% некоего анонима под ником WolfHound.

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


V>>Но если весь и-нет завален материалами и исходниками про тот же LR(0) — то какие проблемы-то?

V>>Твой "полноценный GLR" — это распараллеленный LR(0).
WH>Так и по GLR полно материалов. И все они без исключения говорят, что GLR тормозит.

Для любых алгоритмов в области разбора по формальным грамматикам обязательно упоминается, где они хороши, а где не очень.
Т.е. пытаться что-то там обсуждать в отрыве от вида грамматик и характера входных данных — это махровое дилетанство.
Re[33]: Опциональные типы
Здравствуйте, WolfHound, Вы писали:

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

V>>Ты никуда его не возвращаешь, ты оперируешь им исключительно в том же блоке кода, в котором прочел что-то из входа — я вижу чтение из входа прямо в теле main. Для решения задачи все операции чтения должны быть внутри некой ф-ии, которая вызывается из main, внутри себя читает вектор и возвращает его вызывающему коду. Иначе слил.
WH>1)Это тебе голоса в голове напели.

Т.е. ты слил?


WH>2)Так ты повторишь этот код на хаскеле или таки опять расписался в том, что трепло?


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


V>>Как сформулируешь очередную "задачку, с которой справятся только ЗТ", так приходи.

WH>Так я уже сформулировал. То, что ты не в состоянии написать код это подтверждает.

Пока что я вижу, что ты не в состоянии написать код, который вернет вектор из некоей ф-ии, внутри которой сам вектор будет прочитан динамически. Мне требовалось именно это и ты это прекрасно понял.
Потому что твоя постановка вопроса вот тут:

Попробуй вернуть этот вектор в функцию main таким образом, чтобы тип сохранился.

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

В реальной жизни трюка с вызовом полиморфного колбэка (стиль CPS) — достаточно, особенно если этот трюк поддерживается синтаксисом языка: аппликациями или монадами. Остальное — это лирика и верчение ужей на сковородах.


WH>>>2)Ты даже упрощённый вариант показать не можешь. Ибо трепло.

V>>Ибо прикольно быть модером и хамить, верно?
WH>Ну так код то будет или как всегда трепло?

Моё "код в студию" равносилен утверждению, что подобное невозможно.
И, судя по тому, что ты НЕ в состоянии показать обещанное — я опять прав, а ты опять слил.

Вот тут у тебя фигня полная написана, а не обещанное:
http://www.rsdn.org/forum/philosophy/6716357.1

Итого — трепло.


V>>По этой теме уже всё с тобой ясно — ты не в состоянии показать только что тобой же обещанное.

WH>Ясно что ты не можешь написать десяток строк кода.

Да нечего там писать.
Обещанное тобой не имеет решения.
По крайней мере на Idris.
В общем, ты опять показал своё плохое понимание зависимых типов.


V>>Он как раз регулярно тут хамит окружающим.

V>>Намного-намного реже тебя, но, таки, регулярно.
WH>Окружающим это тебе?

Я тут участвую далеко не во всех темах, больше читаю и то, менее 10%.
У меня довольно-таки узкий круг тем, по которым я регулярно отписываюсь.

Это ж ты у нас везде поспел, как же. ))
Помнишь свою фишку про "capability"?
Ты ведь так и НЕ понял того трюка, что самое смешное. ))
Там прикол в том, что и сами авторы тоже не поняли суть собственного трюка. Такие же дилетанты, фиг ле.

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

Этот трюк легко выражается через создание семейств "несовместимых" типов-контейнеров, хранящих внутри себя "совместимые" типы по-значению.
Вот и всё кино.
Остальное — синтаксический сахар, не более.

В данном случае они назвали этот синтаксический сахар capability и поэтому вылетели с красной карточкой за границы теории типов (за любую из теорий типов), поэтому, следующую игру пропускают. ))

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

Ты не смог ни первого, ни второго.
Твои объяснения были сумбурными, непоследовательными и нелогичными.
Мне пришлось читать про ту хрень самостоятельно и долго над авторами и тобой ржать. ))


V>>Я такой подход хорошо знаю — нахвататься по верхам и тешить своё ЧСВ за счет окружающих.

WH>Это про тебя.

Ага, это я, значит, не мог 8 лет сообразить, что мне говорят? ))
Это я, значит, не отличаю compile time от runtime?
Или это был некто WolfHound? ))
Кончай ломать комедию. Ты откровенно тормозил огромное кол-во лет. Чудовищное кол-во лет по меркам IT.


V>>Стоило только чуть ноготком подцепить и выяснилось, что он сам в этой теории изрядно плавает.

WH>Да ты её вообще не знаешь.
WH>Путаешь рода типов и классы типов. Да ещё сорта типов придумал.

Я как раз не путаю, я как раз говорю — где у нас терминология конкретного языка программирования, а где общая теория типов (какой-то из теорий, бо их больше одной).
А вот ты путаешь терминологию отовсюду.
В общей теории типов есть только одна иерархия: терм, тип, мн-во типов.
Это всё.
Остальное — конструкторы типов и ф-ий разной замысловатости: П-функции (полиморфные), П-типы (зависимые), E-типы (зависимые от литералов) и т.д.

А ты там херню писать изволил.
Потому что рода и классы типов — это терминология сугубо Хаскеля.
И тебе многократно это говорилось, но ты спишь, пока в форум пишешь, вестимо.
Невнимателен, не собран.

Далее.
Под "сортами" типов многие авторы подразумевают НЕСОВМЕСТИМЫЕ м/у собой типы и прямо об этом говорят.
Примеры сортов типов я тебе приводил.
Кароч, у тебя дикая каша в голове из обрывков информации.


V>>Как и ты, который НЕ понимает, что есть "сорта типов". )))

WH>Только в твоей голове. В теории типов их нет.

Ага, всё-таки почитал кое-что?
Молодец!
Вот в другой раз сначала читай, потом возражай.


V>>Я ведь именно тебе (единственному из этих 3.5 человек) МНОГОКРАТНО говорил, что конкретно у тебя проблема в том, что ты зачастую и не хочешь знать. Лично мне со стороны даже где-то обидно за незнакомого мне человека — вроде голова твоя соображать умеет (что приятная редкость, прямо скажем), а вроде часто по верхам, кусочно гладко, не систематично и вообще... Жаль, просто жаль... Потому что у других, кто тут регулярно психует, скажем прямо, проблемы совсем другого плана, я бы даже сказал — местами совершенно непреодолимого плана. ))

WH>Проблемы непреодолимого плана тут только у тебя.
WH>Настолько упёртого невежду я ещё не видел.

Т.е. это я 8 лет упирался по элементарным вопросам? ))


V>>Вы ж разогнали всех более-менее интересных собеседников с этого сайта в разные годы.

WH>Это таких же безграмотных, как и ты?

В этом споре в безграмотных ходишь ты и еще долго будешь.

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

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


V>>- на шаблонах это всё заняло бы примерно столько же времени, сколько потребовалось бы лишь для того, чтобы закодировать предметную область для кодогенерации (и это еще БЕЗ самой генерации).

WH>И очень хорошо зная возможности шаблонов я выбрал внешнюю кодогенерация, ибо знал что шаблоны на этой задаче сдохнут.

На приведенной формуле они не сдохнут.


WH>Ты конечно можешь легко опровергнуть мои слова показав решение на шаблонах.


Показать решение должен был ТЫ, коль утверждал, что получил решение ЛУЧШЕ.
Потому что вопрос стоял так — лучше чем "что"? ))
Сравнение где?
В общем, вменяемого ответа не было, детсад.
Оставалось глумиться.

Решений может быть мильон, сходу накидал, даже не компиллировал, но это пофик, общая идея понятна:
typedef float f;

struct Color8Bit_Traits
{
  typedef uint8 C;

  static C roundC(f value) {
     return round(value)
  }
};

struct Alpha8Bit_Traits
{
  typedef uint8 A;

  static A fromF(f value) {
     return floor(value * 255.5f);
  }

  static f toF(A value) {
     return value / 255f;
  }
};

struct RGBA8_Traits_Base : Color8Bit_Traits, Alpha8Bit_Traits {
  typedef uint32 pixel;

  static C getR(pixel value) { return value & 0xFF; } 
  static C getG(pixel value) { return (value >> 8) & 0xFF; } 
  static C getB(pixel value) { return (value >> 16)& 0xFF; } 
  static A getA(pixel value) { return value >> 24; } 
  static f getAF(pixel value){ return toF(getA(value)); } 
  
  static pixel make(C r, C g, C b, A a) {
    return makeUInt32(r, g, b, a);
  }

  static C mixC(C u1, f a1, C u2, f a2) {
      roundC(u1*a1 + u2*a2);
  }
};

template<typename Traits>
struct RGBA_Traits : Traits {
  static pixel blend(pixel p1, pixel p2, f mix) {
    f a1 = getAF(p1) * mix;
    f a2 = getAF(p2) * (1 - mix);

    C r = mixC(getR(p1), a1, getR(p2), a2);
    C g = mixC(getG(p1), a1, getG(p2), a2);
    C b = mixC(getB(p1), a1, getB(p2), a2);
    C a = mixC(getA(p1), a1, getA(p2), a2);

    return make(r, g, b, a);
  } 
};

typedef RGBA_Traits<RGBA8_Traits_Base> RGBA8_Traits;
// и т.д.
// ...


Итого, алгоритм для ВСЕГО rgba-семейства содержится в некоем RGBA_Traits.
Аналогично надо описать алгоритмы для hsl, cmyk и т.д.
По-сути, получаются ортогональные координаты:
— способы кодирования цвета;
— битовая упаковка.

Сложности тут надуманные.
Я НЕ верю, что ты бы не решил эту задачу.


WH>Но как мы уже выяснили код ты писать не умеешь.


Голоса в голове...


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

WH>Очень даже причём. Вы же пытались гнать бред про то что там всё можно обобщить. Я показал почему нельзя обобщить.

Нихрена ты не показал.
Нужно было или дать сравнение двух подходов или ничего не утверждать, а тихо слиться.
Потому что иначе твоё решение выглядит НЕОБОСНОВАННЫМ.


WH>>>И суперпупермегабыстрый GLR я до сих пор жду. Ни LR(0) или что там тебе ещё голоса в голове напоют, а полноценный GLR.

V>>Я никому не обещал никакой код, с чего ты взял-то?
WH>С того что ты утверждаешь то что противоречит всем работам по GLR.

Брехня опять.
Я раз 10 повторил сценарии/условия, где GLR себя хорошо показал.
Вместо разбора сценариев и озадачиванием — а ПОЧЕМУ так происходит с этим алгоритмом на этих сценариях, ты потребовал некий код.
Т.е., думать ты отказался сходу.
ОК.
Но ты опять этим забавен.


WH>А значит тебе нужно либо доказать свои слова кодом


Пока что всё тобой озвученное лишь означает, что мне надо проделать некую немалую работу по выдиранию алгоритма из боевого проекта, и всё только для того, чтобы заинтересовать с вероятностью 0.3% некоего анонима под ником WolfHound.

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


V>>Но если весь и-нет завален материалами и исходниками про тот же LR(0) — то какие проблемы-то?

V>>Твой "полноценный GLR" — это распараллеленный LR(0).
WH>Так и по GLR полно материалов. И все они без исключения говорят, что GLR тормозит.

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