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

F>Ноборот, в GLR говорят совремегный C++ разбирать легче. Но по голому факту: мэйнстрим фронты используют ужаснейший recursice descent.
GLR, GLL, Earley или любым другим алгоритмом, умеющим парсить все контекстно-свободные грамматики разбирать естественно проще чем неким огрызком, которому то одно правило не нравится то другое.

F> Я без бюсысли на уого-то из вас наезжать — и твк ясно спор — давний и я тут — лишний. Я просто дал уточнение — что фронты совоеменных языков нмкогда не используют LR. Но фронты развивающихся — юзают.
Просто быстрое начало. В начале разработки нитры тоже в качестве парсера использовался ужос. Но когда нитра заработала ужос выкинули и заменили на нитру.

F>Потом тх пернрисыют на рукописные recursive descent. Блин! Да даже никому неизвестный loci постигла эта же участь.
Вот я и говорю, что это жжжжжжж не с проста.

F>>> — сложно сообразить вменяемый еррор репортинг;
WH>>А вот тут пофигу.
WH>>Парсер нитры не генерирует сообщения об ошибках.
F> Ты забываешь, что не нитрой единой.
Я ничего не забываю. Просто говорю, что парсеру не обязательно генерировать сообщения об ошибках.
Их можно сгенерировать по полученному АСТ.
Так получается проще и качественней.

И эту технологию можно применить к любому парсеру.

F> Вопрос ровно в одном — дать коду стэк разбора. Если их предложить штук 100 — то ясен фиг будет порногоафия. Прошу учесть, что это не про нитру.
В общем случае там не стек, а DAG стеков. И я не только про нитру говорю.
А вообще про все парсеры которые могут возвращать лес деревьев.

F> Т.е. ты считаешь что нисходящие (аля top-dow и recirsive-descent но тут я вообще подход имею ввилу — т.е более общем смысле) лучше?
У меня нет полной уверенности. Но жжжжжж которое доносится из всех промышленных решений говорит, что с восходящими явно что-то не то.
Может просто очень сложно. А может есть фундаментальные проблемы. Я не знаю. И исследовать этот вопрос не хочу.

F> Однако, и у тебя и у меня возникает вопрос — неужели нельзя бы было сгенерить?
Нельзя. До сих пор все генераторы парсеров создавались для того чтобы статью в журнал написать. И к реальной работе пригодны небыли.
По крайней мере я до сих пор не слышал ни об оlном генераторе парсеров который создавался бы как инструмент для создания промышленных решений не уступающих рукописным парсерам.

F> Насчет бутстрапа — мне кажется что любой вменяемый ЯП захочется бутстрапиться. С нитрой *пока* что это не выглядит возможным.
1)Не любой. Например, как ты будешь SQL бутстрапить? Да и зачем?
2)Нитра уже частично бутстапится.

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

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

Короче переписывать компилятор, созданный на нитре на любом другом языке просто глупо. Это огромная работа, которая ничего не даст, а только усложнит поддержку и развитие компилятора.

F> Так и с нитрой — инструмент на сегодняшнмй — аховый. Я уже спрашивал... Влад очень подробно объяснил. Но, на сейчас: по факту — или ты живешь с рантаймом да ещё под дот нетом или бери любой другой инструмент (удовлетворяющий задаче).
В чём проблема компилятору языка быть написанным на .НЕТ?
.НЕТ в нужном объёме сейчас есть везде. И на машину разработчика поставить его не проблема.
А сгенерированный код может быть любым. И о .НЕТ даже не догадываться. Таким образом в продакшене .НЕТ не нужен.

F> Ты пойми правильно — мои выпады о стратегии развития и они реальны.
Я просто так и не понял, что у тебя за выпады.

WH>>Разница в том, что автор ANTLR4 профессор. Ему нужны статьи, а мне от них ни жарко, ни холодно.
F> Но ими можно доказать людям что впша придумка не фикция.
Нельзя.

F>Это раз. Во-вторых — профессору пришлось потратить 20 лет на эту статью. WH — ты вот недавно предложил человпку парсер в другом форуме — всё супер. Но... если бы ты дал ссылки на внешние ичточникм — было бы хорошо. Но ещё лучше — если бы ты описал все свои чаяния и/или нитра алгорттм в любой доступной тебе форме.Если профессор сука потратил 20 лет на сраный кеш правил и назвал это ALL — неужели ты не можешь что-то подобное совеошить?
Алгоритм нитры это промышленное, а не академическое решение. И как следствие это не красивый алгоритм, а жуткий монстр. Примерно, как IntroSort (сборная солянка из нескольких сортировок) только намного сложнее.
Я устану его описывать.
Тем более что у меня есть желание неслабо его переделать.
Нужно только с духом собраться.

F>Тем более кау я слышал нитра там ошибки генерирует красивые.
Ошибки Влад генерирует по АСТ которое создаёт мой парсер.
https://github.com/rsdn/nitra/blob/master/Nitra/Nitra.Runtime/Errors/ErrorCollectorWalker.n
Подобный алгоритм можно применить и к другим парсерам.
Главное, чтобы при обходе АСТ можно было понять, что ветка сломана и можно было получить метаинформацию для этого правила.

F> Если не ново — тогда простите. Выдаваьось за ноухау. Я сбил спесь наполовину. Та блин. я лично сбил спесь от немерле.пег на 90% и то — то что — было — это круто.
Я вообще не понял, что тут написано.

F> Имхо просто не все могут задачу осознать. Но короче — мое сугубое имхо — или ЯП с помощью нитры смогут сами себя компилировать (без ВМ разумееися). Либо...
Как я уже сказал это крайне неправильное мнение.
Так делать не нужно не по тому что у нитры на данном этапе есть технические проблемы, которые будут со временем решены, а по тому что это просто неправильно.
Ибо такой подход ведёт к огромному перерасходу ресурсов и значительному ухудшению качества конечного продукта.