Здравствуйте, WolfHound, Вы писали:
Первый вариант ответа — уничтожен телефоном. С...Повторяюсь но короче.
UPD: Первое — было стройнее. Этот ответ более скомканый. Еханый андроид. Больше длинных сообщ никогда не буду писать — после свитча между приложениями он перегружает вкладку — мое недописанное сообщение... его и не было получается как бы. Этот ответ в целом повторяет первое — но т.к. устал! и вообще — реально расползлость не совсем так как изначально и правильно. Иногда ответ по факту предшествует квотации. Но всё равно рядом по смыслу. Сорри.
F>> Ну, GLR ещё хорош тем, что он легко комбинируется с другими крамматиками для создания языков с вложенными языками. The Spoofax Language Workbench его и используют (SGLR).
WH>Тоже мне рокетсайнс.
WH>Нитра вообще может грамматику во время разбора изменять.
Что-то я не понял из примера ничего. Забей.
F>>Но мне не попалась ни одна статья где бы *GLR был реально быстр по сравнению с другими. Но я с удовольствием бы посмотрел на такой, лучше на примере грамматики c/java-подобного языка, если таковые существуют. Кажется я повторяюсь. Ы.
WH>Вот мне тоже не попадались такие статьи.
Интереснее не сколько статьи, а реальные реализации. Вот я нутром чую что компиляция 80к модулей с 800мб исходами — вместо нынешних 2х часов — легко бы уплыла в 3. Но нутро — не показатель. Нынешние 2 часа это конечно реальные плюсы но с LTO. Т.е. они конечно дохера работы делают, но и линковка (кодогенерация) вполне может на пол часика залипнуть но в 2 часа это не входит. Но — интуиция — увы — не показатель. Более того — даже (что скорее всего) — если скорость парсинга тут не столь критична — без реальных докозательств судить банально не о чем. Но это просто работает против GLR т.к. по нему относительно мало инфы. В тоже время, ИМХО, фильтрация его леса — математически определены весьма странно, что опять же не делает его хорошим кандидатом для парсинга тех же плюсиков. Короче то что там вокруг есть куча невнятных работ — это факт. Внятные — остаются таковыми безотносительно темы.
Мне довелось почитать работы про 3х мерные построения фракталов. Приятно было читать всё. Как статьи про парсеры — то вода — то реклама — то значки невнятные. Итого — только половина внятных статей. Остальные нужно под микроскопом разбирать. Имхо — работы по GLR в основном — как раз про микроскоп. Так что не удивлюсь что мы вме не умеем его готовить.
WH>Ужос это рукописный парсер который валился на первой ошибке.
WH>Сейчас для разбора нитры используется сама нитра.
Но ты ж как-то бы мог классифицировать используемый алгоритм?
WH>Теоретически лучше всего восстановление после ошибок работает у рукописных парсеров в которые на каждый чих можно вставить костыль.
Имхо, в рукописниках — там как раз костылей меньше чем можно подумать. Думаю что логично вставлять — минимально необходимые. Мощность же ручных костылей от автоматического восстановления по правилам (или даже совсем без правил) — думаю сравнима. Тут же ж качественный алгоритмический скчаек — RD просто обязаны делать вручную, в то время как генерируемые — нет.
WH>Но это огромные затраты ресурсов. Десятки человеко-лет для того чтобы рукописный парсер C# стал работать лучше, чем тот что написан на нитре в её нынешнем состоянии. А со временем алгоритмы нитру будут улучшаться, и история с ассемблером и ЯВУ повториться на новом уровне.
Я походу чёт лишнего стер. Кратко — не быть тебе евангелистом.
Я говорю — вариант использования нитры с zero-work со стороны команды нитры — а ты говоришь что это плохо и десятки человеко лет.
F>> Почему нитра должна быть написана на нитре — мне понятно. Почему ЯОП не должен быть написан сам на себе — непонятно.
WH>По тому что тебе придётся потратить минимум в 10 раз больше усилий чем на нитре для того чтобы получить что-то что хоть как-то работает.
Технологически — ты щас говоришь рекламный слоган. На сейчас — нитра — нехилая неотделяемая зависимость которая тянет за собой дотнет. Сколько и кто на что потратит — не суть. Я говорю об технологических ограничениях использования — ты же придумываешь что-то вообще извне. С чего в 10 раз больше-то? Без знания целевого языка — ты вообще не можешь делать оценок.
WH>Ты пойми простую вещь. Нитра она как SQL. На ней нельзя писать, что попало. Совсем нельзя. Она заточена исключительно на разработку компиляторов.
Но разве пользователь не может хотеть компилятор внутриклиентского приложения? Компилятор/транслятор запросов — ныне — широкая практика. А формализма — хватает для использования генераторов парсеров. Ну или ad-hoc.
WH>И именно это позволяет нитре иметь такое же преимущество при разработке компиляторов как SQL имеет при написании запросов к RDB.
Угу. При этом RDB — хочет парсить запрос. При этом лишь одна RDB имеет дотнет. Очень смешно.
WH>>>Короче переписывать компилятор, созданный на нитре на любом другом языке просто глупо. Это огромная работа, которая ничего не даст, а только усложнит поддержку и развитие компилятора.
F>> Я об этом и говорю. Впрочем ничего не мешает использовать Нитру только для прототипирования грамматики и/или языка.
WH>Ты говоришь прямо противоположное.
В общем я на этот тезис ответил выше — про евангелизм. Я сказал можно, я не сказал нужно. Причем это вполне может быть логично и оправдано. Кто заставляет использовать всё сразу? Насколько я знаю — никто.
WH>>>В чём проблема компилятору языка быть написанным на .НЕТ?
F>> В том, что к нему могут быть предъявлены иные требования, чем те, которые ты считаешь удобными.
WH>Какие конкретно?
Дотнет? Я выше сказал — SQL парсер не хочет дотнет в another mysql. Для ЯОП — это вообще смешно. Там как бы хочется кросс-платформной компиляции, при том в минимальных средах. Веры в дотнет как повсеместно доступный продукт — небыло, нет и не будет. Подобно бутстрапу компилятора — бутстрап системы тоже начинается с ограниченного набора тулзов. Тулзы которые имеют тупые технологические ограничения (сюда включается банально слишком сложная машинерия что-бы что-то собрать) — просто покидают список и идут на следующий уровень.
Технология — это возможности, а не ограничения. Так или иначе Влад отлично расписпл что необходимо что-бы сделать Нитру более податливой в этом смысле.
F>> На андроиде по факту его нет. А вот нэйтив — есть.
WH>Тебе не нужен компилятор на андройде. Ибо кросс-компиляцию никто не отменял.
Ещё раз — продукт — есть то что должно встраиваться в любое приложение. Сейчас — продукт — это внешнее приложение под дотнетом со всеми вытекающими ограничениями. Это не так плохо, но это — ограничение. Для мобильного мира — так точно.
F>> Парсер / компилятор — может быть частью продукта, поставляемого банально вместе с мобильным приложением.
WH>1)Со временем нитра будет нативной.
Дай бог. Нитра как раз может крутиться спокойно на ботнете вечно. А вот продукты — нет. Нт скорее всего ввиду устройства — она сама смлжет быть нативной. И то хорошо. Но это не про сейчас. Там работы... больше чем написать 10 парсеров С++ с нуля.
WH>2)Это что-то очень узкоспециализированное. Можешь привести пример и оценить объём рынка таких продуктов по сравнению с остальными мобильными приложениями? Больше 0.001% или меньше?
Это не честно такое спрашивать меня. Спроси себя сам — ответ будет приблизительно той же точности и как результат — ниочём. Тема вообще узкая. Что делает твоих юзеров — до дефолту хотя бы средними а скорее всего — много выше. В итоге — они хотят внятных объяснений/данных и т.п. Иначе просто протолкнуть может быть в сотни раз сложнее. Опять же — чисто ИМХО.
WH>3)Если мне не изменяет память apple тупо запрещает чужие компиляторы и интерпретаторы на их мобилах.
Слышал о swizzling? Без него — в этом прекрастном мире apple — просто невозможно. Так что я бы не поминал их вообще если честно.
Пусть они назовут красным — синий — они всё равно будут ехать на юг и никто серьезно не будет на это недоразуменее обращать внимание.
