Здравствуйте, WolfHound, Вы писали:
F>>Ноборот, в GLR говорят совремегный C++ разбирать легче. Но по голому факту: мэйнстрим фронты используют ужаснейший recursice descent.
WH>GLR, GLL, Earley или любым другим алгоритмом, умеющим парсить все контекстно-свободные грамматики разбирать естественно проще чем неким огрызком, которому то одно правило не нравится то другое.
Ну, GLR ещё хорош тем, что он легко комбинируется с другими крамматиками для создания языков с вложенными языками.
The Spoofax Language Workbench его и используют (SGLR). Но мне не попалась ни одна статья где бы *GLR был реально быстр по сравнению с другими. Но я с удовольствием бы посмотрел на такой, лучше на примере грамматики c/java-подобного языка, если таковые существуют. Кажется я повторяюсь. Ы.
F>> Я без бюсысли на уого-то из вас наезжать — и твк ясно спор — давний и я тут — лишний. Я просто дал уточнение — что фронты совоеменных языков нмкогда не используют LR. Но фронты развивающихся — юзают.
WH>Просто быстрое начало. В начале разработки нитры тоже в качестве парсера использовался ужос. Но когда нитра заработала ужос выкинули и заменили на нитру.
Ужос — это PEG/Packrat с расширениями? Теперь база на чем? На нём же но ещё большим количеством расширений/оптимизаций? Или это уже можно реально классифицировать как-то иначе?
F>>>> — сложно сообразить вменяемый еррор репортинг;
WH>>>А вот тут пофигу.
WH>>>Парсер нитры не генерирует сообщения об ошибках.
F>> Ты забываешь, что не нитрой единой.
WH>Я ничего не забываю. Просто говорю, что парсеру не обязательно генерировать сообщения об ошибках.
WH>Их можно сгенерировать по полученному АСТ.
WH>Так получается проще и качественней.
Но для того что бы получить АСТ — нужно ещё наколдовать восстановление ошибок, а это ещё одна задача. Вы в нитре же вроде вставляли "недостающие" символы и таким образом получалось "правильное" дерево разбора? Я читал пост/статью но уже всё забыл. Вообще я скорее всего неверно/неясно выразился — я прежде всего имел ввиду восстановление после ошибок. А насчет как и где проще и качественней — ну это уже вопрос к разработчикам того или иного языка. Если рукописный парсер видит ошибку и может её правильно идентифицировать прямо при парсинге — почему нет. Скорее всего и восстановление будет от этого зависеть.
F>> Насчет бутстрапа — мне кажется что любой вменяемый ЯП захочется бутстрапиться. С нитрой *пока* что это не выглядит возможным.
WH>1)Не любой. Например, как ты будешь SQL бутстрапить? Да и зачем?
Я безусловно имел ввиду любой язык общего назначения, в результате компиляции которого появляются исполнимые (объектные) модули.
WH>2)Нитра уже частично бутстапится.
Хм. Разве не полностью?
WH>Вообще наша философия в том, что каждая задача должна быть решена на языке заточенным на решение этой задачи.
WH>Нитра это набор языков, созданных для разработки компилятора.
WH>Написание компилятора, на языке, который на это не заточен это в лучшем случае в десятки раз больше работы чем на нитре.
WH>Нитру нужно бутстрапить по тому что она сама по себе компилятор. И лучший способ написать нитру это написать её на нитре.
WH>И не по тому что языки обязательно должны бутстрапиться, а по тому что нитра создана для создания компиляторов.
Почему нитра должна быть написана на нитре — мне понятно. Почему ЯОП не должен быть написан сам на себе — непонятно.
WH>Короче переписывать компилятор, созданный на нитре на любом другом языке просто глупо. Это огромная работа, которая ничего не даст, а только усложнит поддержку и развитие компилятора.
Я об этом и говорю. Впрочем ничего не мешает использовать Нитру только для прототипирования грамматики и/или языка.
F>> Так и с нитрой — инструмент на сегодняшнмй — аховый. Я уже спрашивал... Влад очень подробно объяснил. Но, на сейчас: по факту — или ты живешь с рантаймом да ещё под дот нетом или бери любой другой инструмент (удовлетворяющий задаче).
WH>В чём проблема компилятору языка быть написанным на .НЕТ?
В том, что к нему могут быть предъявлены иные требования, чем те, которые ты считаешь удобными.
WH>.НЕТ в нужном объёме сейчас есть везде. И на машину разработчика поставить его не проблема.
На андроиде по факту его нет. А вот нэйтив — есть.
WH>А сгенерированный код может быть любым. И о .НЕТ даже не догадываться. Таким образом в продакшене .НЕТ не нужен.
Парсер / компилятор — может быть частью продукта, поставляемого банально вместе с мобильным приложением.
F>> Ты пойми правильно — мои выпады о стратегии развития и они реальны.
WH>Я просто так и не понял, что у тебя за выпады.
В основном то, что это прибито к дотнету. Я уже спрашивал Влада — Влад подробно всё расписал что нужно предпринять, что бы эта ситуация изменилась. Так этот вопрос можно считать закрытым.
WH>>>Разница в том, что автор ANTLR4 профессор. Ему нужны статьи, а мне от них ни жарко, ни холодно.
F>> Но ими можно доказать людям что впша придумка не фикция.
WH>Нельзя.
Ну людям может быть интересно просто как он устроен и понимать что от него ожидать. Например используется ли backtracking, строится ли лес деревьев и ещё туча вопросов. Врядли кто-то ожидает доскональный алгоритм — но обзорно — вполне.
F>>Это раз. Во-вторых — профессору пришлось потратить 20 лет на эту статью. WH — ты вот недавно предложил человпку парсер в другом форуме — всё супер. Но... если бы ты дал ссылки на внешние ичточникм — было бы хорошо. Но ещё лучше — если бы ты описал все свои чаяния и/или нитра алгорттм в любой доступной тебе форме.Если профессор сука потратил 20 лет на сраный кеш правил и назвал это ALL — неужели ты не можешь что-то подобное совеошить?
WH>Алгоритм нитры это промышленное, а не академическое решение. И как следствие это не красивый алгоритм, а жуткий монстр. Примерно, как IntroSort (сборная солянка из нескольких сортировок) только намного сложнее.
WH>Я устану его описывать.
WH>Тем более что у меня есть желание неслабо его переделать.
WH>Нужно только с духом собраться.
Уже выше написал. Я думаю — достаточно обзорного описания с базовыми принципами.
