Re[7]: Что вас останавливает от изучения нового языка? - Философия программирования

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

A>>>Тебе сколько лет?

VE>>Максималист тут не я.

A>Я не говорил, что ты максималист. Я говорил, что ты отрицаешь очевидные факты про метро.

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

VE>>Даже я ручку выбираю не от балды. Писать-то всякая может, но некоторыми удобнее. А уж писатели и подавно.

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

Я такого не утверждаю, перестань кидаться в крайности. У тебя либо одно не важно, либо другое.

A>А я говорю, что ручка не важна. Чтобы стать Толстым нужно поучаствовать в обороне Севастополя.

Важно и то, и другое. Ручка менее важна, но это не повод писать гусиным пером.

VE>>Разумеется. Но если знаю, то мерседес предпочтительней.

A>Мерседес предпочтительнее, если он бесплатный.

Либо если денег достаточно.

A>А изучение нового языка (и всех сопутсвующих вещей) не бесплатно.
A>Оно стоит года (а то и нескольких) жизни.

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

VE>>GC, замыкания, АлгТД, лямбды, ФВП, легковесные потоки, иммутабельность: все эти на твой взгляд незначимые плюшки дают возможность писать тот самый алгоритм, а не в очередной раз бороться с языком (в этом плане C++ и правда эталон). Для неспецифических задач (где легковесные потоки, например, позволят на порядок проще написать) разница в простоте написания будет не в разы, но всё же будет заметна.

A>Я не понял, так ты слил что-ли? Все, что ты перечислил никак не помогает решить названную задачу. Вот то есть совсем.
A>Спорим, что я с помощью С++ (плюс голова, разумеется) решу эту задачу быстрее чем ты (любыми средствами)?

Спорим, начинай. Я, правда, не понимаю, что ты этим собираешься доказать, что не языком единым? Так этого никто и не утверждал, а ты всё упрямо опровергаешь.

A>Хочешь еще задачку с сайта Яндекса?
A>Есть Террабайт текстов на русском языке.
A>Нужно найти миллион самых частотных сочетаний из двух слов.

Давай лучше что-нибудь под Erlang возьмём, а ты это на Си++ начнёшь писать?

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

V>>Есть еще важный такой момент. Понимать ЯП — это понимать его до такой степени, чтобы знать, как написать компилятор этого языка. Если Фортран/С/Паскаль/Лисп/Пролог сильный студент 4-5-го курса вполне будет в состоянии написать (пусть не самым оптимальным образом или даже не в полном объеме стандартов, не суть), то вот с этим Меркури или с Хасклелем — 100% обломается. Значит, рано пока.

FR>Тогда схема (без макросов) идеальный вариант, функциональный и императивный язык в одном флаконе плюс очень легко написать транслятор.

У Схемы раскрутка хвостовой рекурсии — обязательная часть стандарта. В остальном это тот же Лисп, с т.з. реализации. Т.е. не принципиально.

FR>То же самое и ML, императивная часть не хуже паскаля, функциональщина полноценная, транслятор тоже несложен и уже есть готовый курс
FR>его написания для студентов http://min-caml.sourceforge.net/index-e.html

Возможно. Стадии редукции типизированных лямбда выражений нам, например, не читали. Поэтому было бы странно требовать реализовать материал вне программы. Если где-то программа соответствует этому предложению — почему бы и нет?

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

D>Потому что как правило "придумать себе задачу" == "высосать её из пальца".

Зависит от того, пишет ли человек что-нить для себя

одобрямс

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

ВВ>Это есть только в транке.

Я так и понял. Когда выложишь бинарник — свистни

ВВ>Я только за.

Вот и договорились

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

V>Это которая была сингулярити?
V>И это масштабируется от систем с 64к памяти до систем с 64гиг памяти? Как стек TCP, например?
И нихрена ты не понял из того что там написано.
Там весь код доказанный.

V>Можно взять Схему — допиленный до функциональной чистоты и имеющий стандарт новомодный диалект Лиспа. Ограничения алфавита Хаскеля, и не очень бросающийся в глаза синтаксис замыканий вряд ли будет способствовать пониманию происходящего. ИМХО, понимать происходящее лучше на чем-нить попроще, а к Хаскелю подступаться уже хоть с каким-то багажом.
По сравнению с синтаксисом лиспов синтаксис хаскеля прост, понятен и логичен.

WH>>Он очень грязный.
V>Например?
Например там IO императивное и может быть где попало.
И вообще читай про Mercury там все написано.

V>Да, есть что подчерпнуть. Но, как я же сказал, там много лишнего для целей логического программирования. Это довольно-таки мощный и универсальный язык.
И что же там лишнего?

V>Есть еще важный такой момент. Понимать ЯП — это понимать его до такой степени, чтобы знать, как написать компилятор этого языка. Если Фортран/С/Паскаль/Лисп/Пролог сильный студент 4-5-го курса вполне будет в состоянии написать (пусть не самым оптимальным образом или даже не в полном объеме стандартов, не суть), то вот с этим Меркури или с Хасклелем — 100% обломается. Значит, рано пока.
Там все проще, чем кажется. Особенно если "не самым оптимальным образом".

V>Хотя, шаблоны плюсов тоже писать обломается. Потому вчерашние студенты и не особо в них разбираются. Потому учить плюсам в полном объеме в ВУЗе мне тоже кажется не очень хорошей идеей. Наследование — да, виртуальные методы — да. Метапрограммирование на шаблонах — нет!
Вот это было как раз в том возрасте

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

Только с тех пор я сильно поумнел.
А ты остался на том же уровне.

V>Ну блин, каждый лишний запуск обхода дерева с каждого его узла по мере обхода верхнего уровня, это +1 к показателю степени сложности. А тут +4. Итого, квадратичная изначальная сложность алгоритма превращается в 6-ю степень. Я понимаю, что глубина правил обычно маленькая, да и % правил именно такого вида может быть небольшой... Но для общего случая сразу режет по глазам.
Это мне вынесло весь мозг.
Сложность данной реализации оптимизатора линейна.
А ты, судя по всему, вообще не умеешь считать асимптотику.

V>Ну так, если предполагается дальнейшее независимая доработка, почему бы не вынести этот код за пределы этой одной мега ф-ии? И не дорабатывать независимо от остальной отлаженной части?
Зачем?

V>Я тут инлайна не увидел, хотя ты дважды его упоминал. Где он?
Смотрим в книгу, видим фигу.

        | Call(name, bp)                =>
          match (weights.Get(name))
          {
            | Some(weight) when weight < 20 =>
              match (getOptimizedRule(name))
              {
                | Some(Fsm as rule) => rule
                | _          => Rule.Call(r.Location, name, bp)
              }
            | _              => Rule.Call(r.Location, name, bp)
          }

И что характерно те люди, которые таки правили, этот код находили инлайн сразу. И даже экспериментировали с ним.

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

V>Потому что не с первого раза понимают, наверно.

Код в котором сплетены несколько процессов говнокод сколько на него не смотри. Понять его нельзя.

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

Для того чтобы они его поняли нужно чтобы они знали что такое сравнение с образцом.
Иначе они сделают тупое выражение лица и скажут что это какие-то кракозябры.

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

Чего?
ДКА минимизирует по-другому... очень сильно по-другому.

V> Сойдемся на термине минимизированный. Обычно же полный перебор не делает. Просто от первого же состояния склеивают остальные возможные состояния до первого конфликта выходных сигналов, потом вводят новое подстановочное состояние и т.д.
Это похоже на преобразование НКА в ДКА.
Но никак не на минимизацию.
Ты либо плохо объясняешь, либо нихрена не понимаешь в автоматах.

V>Остановимся на абстрактном построителе модели документа. Согласись, что никакие подробности его внутренней работы не усложнят и не повлияют на код собственно парсера входного потока. В свою очередь, при построении АСТ мы уже имеем диспетчеризацию либо через нужную ф-ию калбэка (что хорошо), либо через код нетерминала (что чуть хуже,но с выходом на первый вариант внутри). Что мешает там же не просто создать узел АСТ, а сразу его минимизированный вариант?
Инлайн.
Неоптимизированный вариант все равно нужен:
Для вывода типов.
Для подсказок в студии.
Для генерации отладочного кода.

Короче ты влез в тему, в которой ты нихрена не понимаешь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

V>Ммм... LL(к) — это и есть грамматика без левой рекурсии. За то ее и любят писатели компиляторов. Если при построении ДКА получаем конфликт, то применяем один из методов устранения левой рекурсии или факторизацию.
У тебя была притензия к комбинаторам что они затыкаются на левой рекурсии.
Я тебе сказал что ЛЛ(К) тоже ее не умеют.
Что не ясно?

V>Т.е. не более чем для экспериментов по отладке грамматики? Или же можно так и оставлять для продакшн кода?
Продакшен он разный бывает.
Иногда лучше не стоит.
Но обычно пофигу.

V>Да вроде автоматическое построение автомата для LL(1) идет как одна из лаб на 3-м курсе обучения. Не? Приведение грамматики к LL(к), а еще лучше к LL(1) — ИМХО отличная стадия работы перед началом кодирования любого парсера. Все-таки, эффективность LL(к) того стоит.
Бред это.
Алгоритмы разбора из книги дракона тупиковая ветвь.
А то, что их пихают во все щели, замедляет развитие более перспективных техник.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

C>>а кто сказал что я этих концепций не знаю?
VE>Если б знал, писал бы на Nemerle.
Как только мне за это будут платить буду писать на нем. А так же еще на полусотне других языков.

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

V>>Это которая была сингулярити?
V>>И это масштабируется от систем с 64к памяти до систем с 64гиг памяти? Как стек TCP, например?
WH>И нихрена ты не понял из того что там написано.

Как же парит эта манера доставать сылки 5-тилетней давности и размахивать ими. К тому же, размахивать столь криво.

WH>Там весь код доказанный.

Насчет "весь" чушь полная. Вовсе не весь, а тот который выше "пояса безопасности" этой операционки. Так что вопрос относительно масштабируемости в силе.

V>>Да, есть что подчерпнуть. Но, как я же сказал, там много лишнего для целей логического программирования. Это довольно-таки мощный и универсальный язык.
WH>И что же там лишнего?

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

V>>Есть еще важный такой момент. Понимать ЯП — это понимать его до такой степени, чтобы знать, как написать компилятор этого языка. Если Фортран/С/Паскаль/Лисп/Пролог сильный студент 4-5-го курса вполне будет в состоянии написать (пусть не самым оптимальным образом или даже не в полном объеме стандартов, не суть), то вот с этим Меркури или с Хасклелем — 100% обломается. Значит, рано пока.
WH>Там все проще, чем кажется. Особенно если "не самым оптимальным образом".

Если делать полноценный вывод типов, то не так просто.

WH>Только с тех пор я сильно поумнел.

Ну, пока впечатление ровно обратное — потерял форму, спустился на более простые задачи. Да еще пытаешься выдавать их за откровения.

WH>А ты остался на том же уровне.

В какой из областей IT?

V>>Ну так, если предполагается дальнейшее независимая доработка, почему бы не вынести этот код за пределы этой одной мега ф-ии? И не дорабатывать независимо от остальной отлаженной части?
WH>Зачем?

Чтобы экспериментами в одном месте не ломать случайно остальные. А зачем вообще стараются независимые вычисления разносить друг от друга?

V>>Я тут инлайна не увидел, хотя ты дважды его упоминал. Где он?
WH>Смотрим в книгу, видим фигу.
WH>

WH>        | Call(name, bp)                =>
WH>          match (weights.Get(name))
WH>          {
WH>            | Some(weight) when weight < 20 =>
WH>              match (getOptimizedRule(name))
WH>              {
WH>                | Some(Fsm as rule) => rule
WH>                | _          => Rule.Call(r.Location, name, bp)
WH>              }
WH>            | _              => Rule.Call(r.Location, name, bp)
WH>          }
WH>

WH>И что характерно те люди, которые таки правили, этот код находили инлайн сразу. И даже экспериментировали с ним.

Я вижу здесь только одну подстановку: Some(Fsm as rule) => rule. Для остальных опять Call. (Весь код не смотрел, сужу только по этому файлу)

Относительно подстановки FSM, я уже дважды упоминал, что у тебя идет поддержка, аналогичная "расширенной нотации регулярных выражений". Тут например. Ты это и называешь инлайном, что ли? Тю, блин. Я-то думал, у вас там где-то инлайн генерируемого кода разборщика, а не подстановка регулярной части правила, аналогичная операции приведения расширенной нотации регулярных выражений к канонической. Таким макаром инлайн искать можно было долго.

В общем, очередной пример изобретения велосипедов и выдачи за откровения.

Тогда вернемся к оптимизации по мере построения АСТ. Тебе всерьез эта подстановка мешает строить сразу оптимизированный вариант?

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

Угу, что делают с forward reference мы не в курсе. А когда придумаем, скажем что это очередной алгоритм "переднего края"?

WH>А если процессы совместить, то правило может быть не распарсено к тому времени как понадобится инлайн.

Да понял я все эти "рассуждения".

WH>Также для инлайна нужно посчитать, сколько правило "весит". А для этого опять же нужно распарсить все правила.

Если инлайнится только FSM, то считать вес правила не надо. Вообще. Подставляют в любом случае. Или ты хочешь сэкономить сотню-другую состояний автомата? Кол-во состояний напрямую на быстродействие не влияет, уже упоминал.

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

Если по отдельности, то такая же очередь forward reference для обработки и всё. Обрати внимание, что предлагалось алгоритмы каждого способа оптимизации разнести по ф-иям, которые можно будет вызывать из разных мест. Я пока вижу, что вместо событийной модели построения ACT идет поочередная энергичная обработка.

V>>Потому что не с первого раза понимают, наверно.

WH>Код в котором сплетены несколько процессов говнокод сколько на него не смотри. Понять его нельзя.

С чего ты взял про "несколько процессов"? Молодым коллегам обычно непонятен декларативный подход как таковой, потому что за ним "что-то скрывается", а им желательно видеть все происходящее целиком, пошагово в дебаге пройтись чтобы можно было. Ну и, читать код макросов С — тоже некий навык нужен. Как и макросов Немерле, справедливости ради.

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

WH>Для того чтобы они его поняли нужно чтобы они знали что такое сравнение с образцом.
WH>Иначе они сделают тупое выражение лица и скажут что это какие-то кракозябры.

Сравнение с образцом разное бывает. Если бы была ее возможность унификации до значений, то это понимается раньше и проще, чем сопоставление со структурой. Опять же, в исполнении Немерле оно заметно отличается от классического разбора АлгТД, т.е. действительно местами кракозябры и самодеятельность.

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

Чего?
WH>ДКА минимизирует по-другому... очень сильно по-другому.

Твое "по-другому" — это и есть единичный шаг того, о чем я говорю. Только это "по-другому" действительно не гарантирует самый минимальный вариант.

V>> Сойдемся на термине минимизированный. Обычно же полный перебор не делает. Просто от первого же состояния склеивают остальные возможные состояния до первого конфликта выходных сигналов, потом вводят новое подстановочное состояние и т.д.
WH>Это похоже на преобразование НКА в ДКА.

Мде. Преобразование НКА в ДКА (которое без минимизации) "склеивает" только те состояния, в которые происходит переход по одному и тому же входному сигналу. Собственно, это и есть избавление от недетерминированности. А ЛЮБОЙ алгоритм минимизация кол-ва состояний ДКА "склеивает" лишь те состояния, в которых имеем непротиворечивый выход. Разница в алгоритмах только в способе разбиения исходных состояний на классы эквивалентности (заменяемых состоянием преобразованного автомата), но суть у них одинакова. Это по модели Мура. По Милли вариантов больше, но автоматы Милли неэффективны в программном исполнении, их разумно делать в аппаратуре, поэтому не здесь упоминаю.

WH>Но никак не на минимизацию.
WH>Ты либо плохо объясняешь, либо нихрена не понимаешь в автоматах.

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

V>>Остановимся на абстрактном построителе модели документа. Согласись, что никакие подробности его внутренней работы не усложнят и не повлияют на код собственно парсера входного потока. В свою очередь, при построении АСТ мы уже имеем диспетчеризацию либо через нужную ф-ию калбэка (что хорошо), либо через код нетерминала (что чуть хуже,но с выходом на первый вариант внутри). Что мешает там же не просто создать узел АСТ, а сразу его минимизированный вариант?
WH>Инлайн.
WH>Неоптимизированный вариант все равно нужен:
WH>Для вывода типов.

PEG-парсер выводит типы?

WH>Для подсказок в студии.

Конкретно здесь что используется в кач-ве подсказки? Можешь на скриншоте показать?

WH>Для генерации отладочного кода.

Зачем кодогенератору создавать разный код для дебага и релиза? Там же птичья грамота все-равно. Грамматики не отлаживают пошаговым проходом по коду парсера.

WH>Короче ты влез в тему, в которой ты нихрена не понимаешь.

А ну да, у кого-то представления отличаются от твоих, значит он ничего не понимает.

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

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

C>>>а кто сказал что я этих концепций не знаю?
VE>>Если б знал, писал бы на Nemerle.
C>Как только мне за это будут платить буду писать на нем. А так же еще на полусотне других языков.

Это был сарказм

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

V>Как же парит эта манера доставать сылки 5-тилетней давности и размахивать ими. К тому же, размахивать столь криво.
June 2010
Это пятилетняя ссылка?

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

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

V>Ну, пока впечатление ровно обратное — потерял форму, спустился на более простые задачи. Да еще пытаешься выдавать их за откровения.
Чего сложного в "типизированная система преобразования физических величин"?
Это же тупой примитивизм.

V>Чтобы экспериментами в одном месте не ломать случайно остальные. А зачем вообще стараются независимые вычисления разносить друг от друга?

То-то ты предлагаешь оптимизатор с парсером совместить

V>Я вижу здесь только одну подстановку: Some(Fsm as rule) => rule. Для остальных опять Call. (Весь код не смотрел, сужу только по этому файлу)
Ты что сказать то хотел?

V>Относительно подстановки FSM, я уже дважды упоминал, что у тебя идет поддержка, аналогичная "расширенной нотации регулярных выражений". Тут например.
И что? Ты вообще о чем?

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

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

V>Тогда вернемся к оптимизации по мере построения АСТ. Тебе всерьез эта подстановка мешает строить сразу оптимизированный вариант?
Всерьез.

V>Угу, что делают с forward reference мы не в курсе. А когда придумаем, скажем что это очередной алгоритм "переднего края"?
Нормальные люди строят АСТ и дальше уже плевать на forward reference.
Что я и сделал.

V>Если инлайнится только FSM, то считать вес правила не надо. Вообще. Подставляют в любом случае. Или ты хочешь сэкономить сотню-другую состояний автомата? Кол-во состояний напрямую на быстродействие не влияет, уже упоминал.
Автомат сам по себе на быстродействие почти не влияет. И я об этом уже раз сто говорил.

V>Если по отдельности, то такая же очередь forward reference для обработки и всё. Обрати внимание, что предлагалось алгоритмы каждого способа оптимизации разнести по ф-иям, которые можно будет вызывать из разных мест. Я пока вижу, что вместо событийной модели построения ACT идет поочередная энергичная обработка.
И что?

V>С чего ты взял про "несколько процессов"?
Так ты сам постоянно твердишь про то, что парсинг с оптимизатором скрестить обязательно надо.

V>Сравнение с образцом разное бывает. Если бы была ее возможность унификации до значений, то это понимается раньше и проще, чем сопоставление со структурой. Опять же, в исполнении Немерле оно заметно отличается от классического разбора АлгТД, т.е. действительно местами кракозябры и самодеятельность.
Чего? В немеле классика МЛ. Один в один. 1973й год однако.

V>Твое "по-другому" — это и есть единичный шаг того, о чем я говорю. Только это "по-другому" действительно не гарантирует самый минимальный вариант.

Ты действительно нихрена в автоматах не понимаешь.
Совсем.
Мое по-другому делает из ДКА гарантированно минимальный ДКА.
Открой дракона, наконец. Там все прекрасно написано. Даже ты поймешь. Может быть.

V>PEG-парсер выводит типы?

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

V>Конкретно здесь что используется в кач-ве подсказки? Можешь на скриншоте показать?
Запусти студию и посмотри.

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

VE>Это был сарказм

вы как нибуть это отмечайте, а то так не понятно.

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

V>>Чтобы экспериментами в одном месте не ломать случайно остальные. А зачем вообще стараются независимые вычисления разносить друг от друга?

WH>То-то ты предлагаешь оптимизатор с парсером совместить

Я же говорю — теряешь форму. Я предлагал минимизировать по мере парсинга. А ты сделал... Действительно смешной вывод.

V>>Я вижу здесь только одну подстановку: Some(Fsm as rule) => rule. Для остальных опять Call. (Весь код не смотрел, сужу только по этому файлу)
WH>Ты что сказать то хотел?

Что искал классический инлайн.

V>>Относительно подстановки FSM, я уже дважды упоминал, что у тебя идет поддержка, аналогичная "расширенной нотации регулярных выражений". Тут например.
WH>И что? Ты вообще о чем?

Что сия фича была замечена и ранее, и она для описания FSM весьма популярна.
Т.е. вот пример расширенной нотации регулярных выражений:

rule digit = choice("0123456789");
lexema number = digit+;
lexema kg = number & "kg";

Чтобы сгенерировать ДКА по этой системе, производят подстановку правил number и digit. Термин "инлайн" к этому процессу первый раз слышу. Хотя, не принципиально.

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

Значит, код, который "раньше" и нужно было приводить, как пример инлайна.

WH>Просто это смысла не имеет.
WH>А зачем инлайнить генерируемый код когда гораздо проще заинлайнить модель по которой код генерируется?

ИМХО, никакого классического инлайна вычислений, сопровождающимся ребиндингом аргументов, тут нет. Вот пример инлайна:
inline plus(int a, int b) { return a+b; }

При подстановке этой ф-ии, например сюда: return plus(a.x, b.x); происходит ребиндинг аргументов а и b на реальные параметры a.x и b.x, со всеми преобразованиями кода, связанными с особенностями получения их значений, т.е. генерируется новыйкод по "шаблону" заинлайненного выражения, а не подставляется имеющийся без изменений. Хотя, в вырожденном случае возможна подстановка без изменений, но у тебя только вырожденный случай и есть.

А я уже было чуть не заинтересовался...

WH>Более того после инлайна еще и оптимизация идет которую на сгенерированном коде не сделать.

Блин, как нудно. Обработка системы правил перед реализацией парсера — это обязательная стадия. Всегда. Реально весело читать все это, сопровождаемое пафосными "более того". А покажи, где у тебя выявляются и отбрасываются тупиковые ветки грамматики? Ну чтобы потом ты мог сказать "более того, у нас еще и тупиковые ветки отбрасываются, представляете?!!"

Или нету этой стадии обработки правил в вашем "переднем крае"?

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

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

V>>Угу, что делают с forward reference мы не в курсе. А когда придумаем, скажем что это очередной алгоритм "переднего края"?
WH>Нормальные люди строят АСТ и дальше уже плевать на forward reference.

Да пофиг, коль мы уперлись в обсуждение — возможно это или нет. Ответа "мне так удобней" было бы достаточней, чем пытаться доказать, что это невозможно. Бо ты сильно ошибаешься.

V>>Если инлайнится только FSM, то считать вес правила не надо. Вообще. Подставляют в любом случае. Или ты хочешь сэкономить сотню-другую состояний автомата? Кол-во состояний напрямую на быстродействие не влияет, уже упоминал.
WH>Автомат сам по себе на быстродействие почти не влияет. И я об этом уже раз сто говорил.

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

V>>С чего ты взял про "несколько процессов"?
WH>Так ты сам постоянно твердишь про то, что парсинг с оптимизатором скрестить обязательно надо.

В событийной модели, или как тут модно называть ее "реактивной", это делается естественно. Только мне термин "скрещивать" не нравится. Зароутить события м/у относительно-независимыми модулями, это не есть их скрещивание.

WH>Мое по-другому делает из ДКА гарантированно минимальный ДКА.
WH>Открой дракона, наконец. Там все прекрасно написано. Даже ты поймешь. Может быть.

Дай имя алгоритма, который подразумеваешь.

V>>А ну да, у кого-то представления отличаются от твоих, значит он ничего не понимает.
WH>Ты просто несешь бред.
WH>Твои понятия просто несовместимы с создание промышленных компиляторов.
WH>Одна оптимизация во время парсинга чего стоит.

WH>Оптимизация это потеря информации.
WH>А без этой информации ни навигацию, ни сообщения об ошибках нормально не сделать.

Да что ты? И как же компилятор С++ позволяет даже в оптимизированном варианте сохранять, при надобности, дебажную информацию о соответствии исходного кода, и даже пошагово ходить по шаблонным и заинлайненым ф-ям? А ведь всё честно заинлайненно по самое нихочу. А может "передний край" тут в том, что сохранить сответствие строк исходника и даже самого оптимизированного бинарника не так уж сложно?

Ты понимаешь, что вообще все твои аргументы пока что из разряда "вы все дураки, один я умный". Ни одного по делу. Что конкретно мешает сохранять соответствие м/у исходными правилами и генерируемым, даже самым оптимальным кодом. Вот давай, с подробностями и примерами.

WH>Типизацию на оптимизированном АСТ тоже не сделать.

Походил я там по исходникам... У вас же нет в PEG-парсере той типизации, которая требует перебора, т.е. логического программирования. И бета-редукции нет. Что и где там не получится "типизировать"? Называй файл/метод/ф-ию, которые перестанут работать.

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

WH>Вон спроси у Влада, что он думает о том, что поляки в компиляторе немерла не всю информацию полученную при разборе текста сохраняют. Услышишь много громкого мата. Я гарантирую это.

Сохраняй информацию, в чем проблема.

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

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

WH>>То-то ты предлагаешь оптимизатор с парсером совместить

V>Я же говорю — теряешь форму. Я предлагал минимизировать по мере парсинга. А ты сделал... Действительно смешной вывод.
Так это и есть парсинг с оптимизатором совместить.
Это лапша!

V>Что искал классический инлайн.
Что значит классический?

V>Чтобы сгенерировать ДКА по этой системе, производят подстановку правил number и digit. Термин "инлайн" к этому процессу первый раз слышу. Хотя, не принципиально.
Так там много чего инлайнилось. Просто сейчас остался один ДКА ибо другое инлайнить нет смысла тк на производительность не влияет.

V>Значит, код, который "раньше" и нужно было приводить, как пример инлайна.
А это тебе чем не инлайн?

V>ИМХО, никакого классического инлайна вычислений, сопровождающимся ребиндингом аргументов, тут нет. Вот пример инлайна:
Ну то есть по твоему инлайн может быжет быть только когда мы имеем дело "обычным" кодом?
А когда мы берем другую модель кода, то инлайн уже не инлайн.
Смешно.

V>Да пофиг, коль мы уперлись в обсуждение — возможно это или нет. Ответа "мне так удобней" было бы достаточней, чем пытаться доказать, что это невозможно. Бо ты сильно ошибаешься.
И как ты собрался инлайнить в процессе парсинга правило которое еще не разобрано?
АСТ нет. Его еще из текста не достали.
Что ты инлайнить то собрался?
Давай расскажи.

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

V>Дай имя алгоритма, который подразумеваешь.
Hopcroft, John (1971), "An n log n algorithm for minimizing states in a finite automaton", Theory of machines and computations (Proc. Internat. Sympos., Technion, Haifa, 1971), New York: Academic Press, pp. 189–196, MR0403320 .

V>Да что ты? И как же компилятор С++ позволяет даже в оптимизированном варианте сохранять,
Ой лол.
В релизе отладка не работает чуть менее чем полностью.
Там куча информации теряется.

V>Ты понимаешь, что вообще все твои аргументы пока что из разряда "вы все дураки, один я умный".
Ты обращаешься к себе на вы?

V>Ни одного по делу. Что конкретно мешает сохранять соответствие м/у исходными правилами и генерируемым, даже самым оптимальным кодом. Вот давай, с подробностями и примерами.
Пропадание кусков АСТ.
FSM в исходном коде нет.
Его из других кусков АСТ делают.

V>Походил я там по исходникам... У вас же нет в PEG-парсере той типизации, которая требует перебора, т.е. логического программирования. И бета-редукции нет. Что и где там не получится "типизировать"? Называй файл/метод/ф-ию, которые перестанут работать.
Запусти оптимизатор перед типизатором и увидишь феервек.

V>Сохраняй информацию, в чем проблема.

Вы уже 5-й год над компилятором работаете, нельзя было доработать моменты, которые в текущем виде не устраивают?
Мы то сохраняем все, что можно сохранить.
А ты тут предлагаешь оптимизатор запустить и все порушить.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

WH>>>То-то ты предлагаешь оптимизатор с парсером совместить

V>>Я же говорю — теряешь форму. Я предлагал минимизировать по мере парсинга. А ты сделал... Действительно смешной вывод.
WH>Так это и есть парсинг с оптимизатором совместить.
WH>Это лапша!

Ты отдели на досуге собственно парсер от построителя документа, то бишь AST. А остальное увидишь сам.

V>>Чтобы сгенерировать ДКА по этой системе, производят подстановку правил number и digit. Термин "инлайн" к этому процессу первый раз слышу. Хотя, не принципиально.
WH>Так там много чего инлайнилось. Просто сейчас остался один ДКА ибо другое инлайнить нет смысла тк на производительность не влияет.

Да понял я уже, что ты упрощение правил называешь инлайном.

Что касается профита быстродействия, то что и как мерили? И нафига там, все-таки, прикидка по весам, хоть убей не пойму? Это типа такой эвристики, наподобие алгоритма инлайнера компилятора gcc? Чья идея? Это же не из той области. В стандартном шаге упрощения систем правил производят ПОЛНУЮ подстановку (!!!), т.е. до тех пор, пока не натыкаемся на рекурсию. Заметь, пофиг веса абсолютно. Если же на рекурсию в итоге не натыкаемся, т.е. удается полностью осуществить подстановку всех нетерминалов, то грамматика в результате упрощения вырождается в регулярную. Полную подстановку я вижу только для FSM-участков, а для остальных правил ты не производишь раскрытие Choice.

А коль у вас не полная подстановка, то непонятно что там пытались замерить. Ну и ес-но, что эффект от упрощения особенно заметен только на самом нижнем уровне, это аналогично тому, как имеет смысл оптимизировать вычисления на самом вложенном цикле, потому как оптимизация циклов верхнего уровня заметного профита не дает. Ладно, даже если пользовать эвристику по весам. Я вижу по коду, что вычисление веса слишком косвенно связано с частотой использования (обратно ему), т.к. вычисляет "сложность" правила. Было бы неплохо к весу непосредственно "примешивать" кол-во прямых и транзитивных вызовов, т.е. частоту использования правила, чтобы находить "самые низлежащие" правила. Более того, после беглого просмотра исходников мне кажется, что сам вес в вашей реализации после шага оптимизации может быть изменен, если пересчитать его заново по оптимизированному варианту. Т.е. после пересчета надо запускать оптимизацию снова и так итеративно до тех пор, пока очередной запуск оптимизации не будет "холостым". Кстати, это единственный пока момент, который обосновывает отдельную стадию оптимизации, бо ее надо будет вызывать многократно.

WH>Ну то есть по твоему инлайн может быжет быть только когда мы имеем дело "обычным" кодом?
WH>А когда мы берем другую модель кода, то инлайн уже не инлайн.

К системе уравнений применяют термин "упрощение", а к отдельным выражениям "раскрытие скобок", "подстановка". Явно споткнулись о терминологию. Будем далее за нее бодаться?

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

Наверно, особенность ПЕГ в том, что на тех участках, где нет перебора/откатов, он действительно шпарит как автомат... так же как любой магазинный парсер, например LR.

А может, сие от грамматики зависит? Я вообще считал, что выделение FSM в вашей реализации ПЕГ нужно исключительно ради минимизации кол-ва его состояний, больше незачем. Реальное быстродействие конечно надо искать в оптимизации переборов/откатов, а не в выделении FSM. Бо минимизация состояний на быстродействии почти не сказывается. Вернее, если бы не эффекты кешей процессоров, то скорость работы по минимизированному ДКА в точности равна скорости работы по минимизированному. У последнего просто таблица переходов не такая "разреженная".

V>>Дай имя алгоритма, который подразумеваешь.
WH>Hopcroft, John (1971), "An n log n algorithm for minimizing states in a finite automaton", Theory of machines and computations (Proc. Internat. Sympos., Technion, Haifa, 1971), New York: Academic Press, pp. 189–196, MR0403320 .

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

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

O(m * log n) where m = Q and n = E*Q, where E is alphabet of input symbols of the nite automaton

Небольшое улучшение, надо заметить.

V>>Да что ты? И как же компилятор С++ позволяет даже в оптимизированном варианте сохранять,
WH>Ой лол.
WH>В релизе отладка не работает чуть менее чем полностью.
WH>Там куча информации теряется.

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

V>>Ни одного по делу. Что конкретно мешает сохранять соответствие м/у исходными правилами и генерируемым, даже самым оптимальным кодом. Вот давай, с подробностями и примерами.
WH>Пропадание кусков АСТ.

Ты показательно проигнорировал вот это:

А может проблема в том, что вместо списка локейшенов протягивается один его экземпляр? Поэтому теряется история-цепочка подстановки правил в процессе оптимизации?

Разве куски АСТ цель? А не привязка генерируемого кода к "исходнику"? В С++, например, через прагму можно вставлять в генерируемый исходник ссылки на другой исходник, что позволяет потом проводить пошаговую отладку по исходному файлу DSL, а не по "птичьему коду", порожденному кодогенератором. Может ли нечто аналогичное делать компилятор Nemerle? Всяко удобнее будет шагать по исходной граматике, чем по кодогенеренной абракадабре.

Ладно, спасибо, было немного интересно. Остальное ниже уже пошло по кругу.

	От:	Воронков Василий
	Дата:	26.04.11 08:40
	Оценка:

	От:	alvas
	Дата:	26.04.11 09:13
	Оценка:

	От:	Воронков Василий
	Дата:	26.04.11 09:21
	Оценка:

	От:	VoidEx
	Дата:	26.04.11 09:23
	Оценка:

	От:	vdimas
	Дата:	26.04.11 09:26
	Оценка:

От:	Mystic	http://mystic2000.newmail.ru
Дата:	26.04.11 09:30
Оценка:

От:	hardcase	http://nemerle.org
Дата:	27.04.11 07:41
Оценка: