Кто ж знал, что два маньяка, в 4 утра(!! как гитлир) будут редактировать одно и то же.
VD>К сожалению у нас нет защиты от параллельного редактирования.
Да защиту не обязательно, хотя бы маркер "этот файл был взят на редактирование тем-то тогда-то".
Насчёт перевода на английский... даже не знаю, стóит ли. Из всего потока мыслей, наш "иностранный друг" поймёт разве что стадии компилляции (и это действительно нужный материал). Опять же, нужна чуть более удобная для восприятия версия, где по списку будет легко найти, что сделано/не сделано.
Думаю, вот этот раздел стадий компилляции стоит вынести в отдельную статью и расширить, сделав её как общую документацию к компиляторостроению и роли Нитры во всём этом. Даже пометить цветом, что за вас делает Нитра и как мало вам остаётся реализовать.
Здравствуйте, Kolesiki, Вы писали:
K>Да защиту не обязательно, хотя бы маркер "этот файл был взят на редактирование тем-то тогда-то".
Проблема в том, что нет такого понятия "взят на редактирование". Это всего лишь форма которая может быть закрыта без записи. Отследить факт закрытия окна не просто. Разве что слать через каждую секунду сообщение на сервер "я открыта".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kolesiki, Вы писали:
K>Кто ж знал, что два маньяка, в 4 утра(!! как гитлир) будут редактировать одно и то же.
Кстати, зря ты стал "е" на "ё" менять. Смысл это не менят, а вот куча правок на ровном месте появляется. В русском допустимо использовать "е" вместо "ё". Весь софт на это рассчитан. Даже поиск и проверка орфографии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Правда идет очень медленно в виду моего плохого знания английского. Пока перевел половину. Посмотри, что там можно поправить, плиз.
K>Насчёт перевода на английский... даже не знаю, стóит ли. Из всего потока мыслей, наш "иностранный друг" поймёт разве что стадии компилляции (и это действительно нужный материал).
А чем же наши иностранные друзья хуже то? Тем более, что там есть прямые к ним отсылки. @sirinath там нагенерировал мыслей по поводу системы типво и вообще предложил впихнуть в язык все что в голову придет. Я именно ему попытался объяснить (целым разделом) почему это не надо делать на первых порах.
K>Опять же, нужна чуть более удобная для восприятия версия, где по списку будет легко найти, что сделано/не сделано.
Это уже надо в milestone-ах. Вот как это в Нитре выглядит. https://github.com/rsdn/nitra/wiki/Milestone-2
K>Думаю, вот этот раздел стадий компилляции стоит вынести в отдельную статью и расширить, сделав её как общую документацию к компиляторостроению и роли Нитры во всём этом. Даже пометить цветом, что за вас делает Нитра и как мало вам остаётся реализовать.
Вынесем. Было бы что. Организовать текст проще чем его написать по английски.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
По поводу статьи "Описание языка описания расширяемых парсеров «Nitra»":
Замечание глобальное: много деталей, за которыми не видно леса. Напоминает автогенерённую документацию по аннотациям методов. Если человеку вывалить все инструменты сразу, он просто офигеет и потеряется! Но если по очереди доставать инструменты для каждой задачи, всё будет легко и понятно.
Калькулятор. Самый ужасный, порочный и неправильный пример в области компиляторов — он даёт совсем другое представление о работе, нежели должно быть при работе с АСТ. Мне кажется, куда удобнее был бы простейший язык, типа:
a = 4 + 6 * 3 // переменные и две операции разного приоритета
? a + 1 // печать выражения
Для этого языка создаётся грамматика, АСТ, а затем генерируется код да на том же C#! Но главное, это именно тот процесс, который должен пройти каждый джедай компиляторов — грамматика, дерево разбора, АСТ, связывание имён, обход дерева, генерация кода. Минимальность языка гарантирует, что мы не потеряемся в дебрях, а "разнообразие" — что мы обязательно задействуем основные инструменты Нитры. Разумеется, нужно в каждом удобном случае объяснять, чем нам помогла Нитра, сделав работу за нас.
Да, и ни слова не увидел про ту бриллиантовую фичу, ради которой был потрачен целый год исследований — восстановление после ошибок. Его тоже неплохо бы описать: что мы имели ДО него, что имеем сейчас и как это здорово (лучше в применении к конкретному примеру на игрушечном языке).
После такого примера будет легче увидеть, что за всемогутер у нас в руках — просто перечисление фич не даст ощутить всю (по)мощь Нитры.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, зря ты стал "е" на "ё" менять. Смысл это не менят, а вот куча правок на ровном месте появляется.
Тебя беспокоит количество затёртых байт? Для меня "ё" — полноценная буква алфавита, её проще ВСЕГДА писать, чем думать в каждом случае, не случится ли разночтения! Да и потом, я ж не заставляю — просто самому приятно читать полноценный текст.
Здравствуйте, VladD2, Вы писали:
K>>Да защиту не обязательно, хотя бы маркер "этот файл был взят на редактирование тем-то тогда-то".
VD>Проблема в том, что нет такого понятия "взят на редактирование". Это всего лишь форма которая может быть закрыта без записи.
Неважно. Главное — если текст вообще не трогали, видно, что я его могу спокойно взять на редакцию. Или если его взяли редактировать 2 дня назад — можно спокойно перезаписывать. Короче, с "иногда работающим" маркером намного лучше, чем вообще без него, согласен?
Здравствуйте, VladD2, Вы писали:
K>>Насчёт перевода на английский... даже не знаю, стóит ли. Из всего потока мыслей, наш "иностранный друг" поймёт разве что стадии компилляции (и это действительно нужный материал).
VD>А чем же наши иностранные друзья хуже то?
Тем, что они не знают всей кухни и не в курсе, что мы иногда любим растекаться мыслью по древу То есть в самом-то тексте ты всё правильно написал — есть понимание, что и почему. Но это я знаю тебя и твой проект. А для них это поделка "странных русских" и в её описании должно быть меньше тем для раздумий, тупо алгоритм: "есть Нитра, берёшь и пилишь грамматику!". К примеру, говоря о CCI: "Скорее всего, лучше заменить его на код из Roslyn" — зачем им это знать? (или давать повод для споров) Моё мнение — нужно вообще сторониться Рослин-кода и взять какой-нибудь Cecil (если его возможностей достаточно).
Т.е. на басурманский лучше переводить только те вещи, в которых мы сами уверены и которые будут заметно полезны. Вот стадии компиляции я прочёл с большим интересом, им тоже этот раздел понравится.
K>>Опять же, нужна чуть более удобная для восприятия версия, где по списку будет легко найти, что сделано/не сделано. VD>Это уже надо в milestone-ах. Вот как это в Нитре выглядит.
Нет, речь не о том и не в такой форме. Мы говорим об "абстрактном" компиляторе, который вынужден проходить какие-то стадии и что-то делать. У тебя это расписано. Но для них (остального мира) мы должны объяснить наглядно, разжёвывая каждую стадию и поясняя, что за нас уже сделано самой Нитрой (или планируется). Milestone — это уже конкретные этапы конкретного продукта, кратко расписанные для удобочитаемости.
Кратко, вот в том списке стадий компиляции нужно пометить жирным, что Нитра должна делать за нас (всё, и сделанное, и планируемое), а уже эти жирные части раскрасить синим — сделанные, красным — планируемые. Если какая-то фича — сложная и сделанная наполовину, не грех её разбить на пару предложений и выделить не сделанное. Вот тогда один взгляд на список сразу даст понимание состояния проекта. Да, альтернативы туда тоже нужно внести, может даже блок-схемой: разные бэкенды, разные платформы и т.п.
VD>Вынесем. Было бы что. Организовать текст проще чем его написать по английски.
Ну вот, список стадий уже есть! Ты даже написал про уже сделанные модули, но они нужны в самом списке, а не подстрочником.
Вопрос не в тему: про объединении C+#x$% и Nemerle-2 ты упомянул, что "АСТ можно вынести в общий модуль" — это как и зачем?? АСТ — это же структура в памяти, причём у каждого языка — своя (несмотря на подавляющую схожесть). Рантаймовую структуру вынести в модуль??
Здравствуйте, Kolesiki, Вы писали:
K>К примеру, говоря о CCI: "Скорее всего, лучше заменить его на код из Roslyn" — зачем им это знать?
K>Затем, что это одна из актуальных задач. Сейчас бэкэнд на CCI, но надо попробовать сделать бэкэнд основанный на Roslyn. Это должно быть не очень сложно, так как в Roslyn тупо откопипастили CCI.
K>Моё мнение — нужно вообще сторониться Рослин-кода и взять какой-нибудь Cecil (если его возможностей достаточно).
Это потому что ты незнаком с некоторыми деталями.
Дело в том, что МС расплодил кучу платформ и только Roslyn-овский компилятор позволяет поддерживать их все. Даже у CCI есть проблемы. А у Cecil их еще больше, плюс откровенные баги, которые могут возрождаться (отказываться после исправления).
Мы спроектировали все так, что в принципе можно сделать несколько бэкэндов. Наличие Roslyn-вского бэкэнда никак не мешает наличию CCI-го и Cecil-вского. Да хоть LLVM-го или Java-ного. Но Roslyn-вский дает поддержку определенных платформ, плюс в из кода Рослина можн узнать некоторые решения при генерации кода (которые не тривильны), так что изучение Roslyn-а по любому полезно. Плюс одно может быть кому-то интересно для самообразования (повышения скилов).
K>Т.е. на басурманский лучше переводить только те вещи, в которых мы сами уверены и которые будут заметно полезны. Вот стадии компиляции я прочёл с большим интересом, им тоже этот раздел понравится.
Ну, может у меня на моей колокольни глаз замылен и я вижу все не так как следует, но по-моему, я описал как раз те вопросы которые должны возникнуть у потенциальных разработчиков. Я, как раз, отталкивался от вопросов которые мне уже задавали (в том числе на https://gitter.im/rsdn/nemerle).
K>Нет, речь не о том и не в такой форме. Мы говорим об "абстрактном" компиляторе, который вынужден проходить какие-то стадии и что-то делать. У тебя это расписано. Но для них (остального мира) мы должны объяснить наглядно, разжёвывая каждую стадию и поясняя, что за нас уже сделано самой Нитрой (или планируется). Milestone — это уже конкретные этапы конкретного продукта, кратко расписанные для удобочитаемости.
Честно говоря все равно не понял в чем разница. Milestone — это и есть разжевывание.
K>Кратко, вот в том списке стадий компиляции нужно пометить жирным, что Нитра должна делать за нас (всё, и сделанное, и планируемое),
Нитра — это инструмент. Она за нас ничего не делает. Она предоставляет средства реализации. Ну, как C# или C++. Чтобы понять, что она предоставляет лучше прочесть статьи по ней. К сожалению они тоже все на русском и ты сам тут рядом предъявлял к ним претензии. Возможно поможет чтение Реализация языка программирования Mini C на Nitra
.
K>а уже эти жирные части раскрасить синим — сделанные, красным — планируемые. Если какая-то фича — сложная и сделанная наполовину, не грех её разбить на пару предложений и выделить не сделанное.
Говорить о сделано / не сделано можно только в рамках проектов. Вот в проекте Cx# (он же CSharp.Grammar) коне что сделано. И я описал что. Можно по подробнее расписать этот и другие проекты. Но боюсь, что здесь детализация тоже же будет размывать картину.
K>Вот тогда один взгляд на список сразу даст понимание состояния проекта. Да, альтернативы туда тоже нужно внести, может даже блок-схемой: разные бэкенды, разные платформы и т.п.
Честно говоря, по-моему, для того чтобы дело начало двигаться важно не понимание состояния проекта, а чтобы люди начали мне помогать. Другими словами, чтобы люди из созерцателей превратились в помошников — комьюнити развивающее язык.
Я уже несколько раз закидывал идею начала работы над языками, но все хлапали глазки и даже не вступали в дискуссию. А когда дискуссия спонтанно завязалась на https://gitter.im/rsdn/nemerle, быстро выяснилось, что она перешла в обсуждение где найти по больше фич, которые желательно впихнуть в язык. Вот только я и сам знаю что можно впихнуть я язык. А проблема не в этом, а в том, чтобы начать этот язык равивать.
Даже скажу больше. Проблема в том, чтобы люди начали знакомиться с самой Нитрой. В процессе я как-нибудь объяснил бы детали. И план я тоже могу составить. Это не проблема.
За все время откликнулся только один человек Василий Кириченко. Он даже сделал тот самый пример Mini-C на котором я убедился, что человек со стороны вполне может освоить Нитру. Но потом он тихо исчез. Было еще 2-3 человека которые дальше разговоров не пошли.
Подозревают, что есть какие-то технические и/или психологические аспекты препятствующие активном включению в проект. Но, к сожалнеию нет даже простого фитбэка. Так что я даже не могу выявить эти поблемы.
K>Ну вот, список стадий уже есть! Ты даже написал про уже сделанные модули, но они нужны в самом списке, а не подстрочником.
Я не понимаю, что такое подстрочник. Включать их в сам список — это значит еще больше его раздувать. По-моему, все и так довольно очевидно. В Cx# сделано все до типизации тел методов. Но многое из сделанного еще нужно допиливать напильником (нужна куча дополнительных проверок соответствии спецификации). А не сделаны типизация тел и кодогенерация и сериализация сборок на диск.
K>Вопрос не в тему: про объединении C+#x$% и Nemerle-2 ты упомянул, что "АСТ можно вынести в общий модуль" — это как и зачем??
Ну, вот как-бы об этом я и писал. Вся первая часть этому и была посвящена. Но ты сказал, что это не важные детали, а выходит, что то ли не прочел, то ли не понял.
K>АСТ — это же структура в памяти,
Ну и что что в памяти? У тебя объект — это тоже "структуры в памяти", но чтобы они были тебе же нужно описать классы? Вот и в АСТ нужно описать типы АСТ на освновании которых будут уже структуры в памяти создаваться (в рантайме). Все правила типизации описываются на этих структурах (т.е. на АСТ). И об этом я тоже сказал.
K>причём у каждого языка — своя (несмотря на подавляющую схожесть).
Опять таки и об этом я скзал. 80% таких структур будет одинаковыми (идентичными). Нет смысл описывать их для каждого языка. Уникальные вещи воде паттерн-матчинга — надо. Но кроме них есть еще куча общих вещей. На то он и AST. Первая буква в слове "AST" помнишь, что означает? Это — Abstract. На то он и абстракный, чтобы не зависит от конкретного языка.
K>Рантаймовую структуру вынести в модуль??
У тебя явно путанница между стадиями. АСТ — это рантайм структура компилятора, а не самого языка. Вот текст на языке разбирается и переводится (в памяти компилятора) в АСТ. На АСТ-е прозводятся вычисления и по аннотированному АСТ просзводится уже генерация кода (это упрощенно).
Я описал, что есть проект DotNetLang в котором и собран общий для всех языков АСТ. Уникальный АСТ будет в проектах конкретных языков. Но его будет не много.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kolesiki, Вы писали:
K>По поводу статьи "Описание языка описания расширяемых парсеров «Nitra»":
K>Замечание глобальное: много деталей, за которыми не видно леса. Напоминает автогенерённую документацию по аннотациям методов. Если человеку вывалить все инструменты сразу, он просто офигеет и потеряется! Но если по очереди доставать инструменты для каждой задачи, всё будет легко и понятно.
Ну, я это и писал в расчете в дальнейшем из этого доку сделать. Чтобы ее не читать от корки до корки, а находить нужные фрагменты и уже их изучать досконально.
K>Калькулятор. Самый ужасный, порочный и неправильный пример в области компиляторов — он даёт совсем другое представление о работе, нежели должно быть при работе с АСТ. Мне кажется, куда удобнее был бы простейший язык, типа:
K>
K>a = 4 + 6 * 3 // переменные и две операции разного приоритета
K>? a + 1 // печать выражения
K>
Калькулятор — это классический пример. Его сделали еще во времена когда у нас не поддерживалась типизация (АСТ, символы, области видимости, связывание). Считай, что его сделали по традиции. К тому же он демонстрирует, как работать с деревом разбора без типизации (в режиме простого парсера).
K>Да, и ни слова не увидел про ту бриллиантовую фичу, ради которой был потрачен целый год исследований — восстановление после ошибок. Его тоже неплохо бы описать: что мы имели ДО него, что имеем сейчас и как это здорово (лучше в применении к конкретному примеру на игрушечном языке).
А что тут рассказывать то? Без восстановления вся Nitra на фиг не нужна. Точнее, можно было бы, конечно, заставить писать спецправила на каждый чих, но это очень очень трудозатратно.
Восстановление работает. Для жизни хватает. Не без проблем, но все же. В крайних случаях можно спец-правила писать.
K>После такого примера будет легче увидеть, что за всемогутер у нас в руках — просто перечисление фич не даст ощутить всю (по)мощь Нитры.
Я тут уже приводил гифки анимированные. На них видно как работает редактирвоание и восстановление. Скоро один наш общий знакомый должен выкатить первый коммерческий язык на Nitra. У него уже есть большие видео с процессом редактирования кода на его языке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если бы было написано "съё", неоднозначностей уже бы не было.
K>>Моё мнение — нужно вообще сторониться Рослин-кода и взять какой-нибудь Cecil (если его возможностей достаточно).
VD>Дело в том, что МС расплодил кучу платформ и только Roslyn-овский компилятор позволяет поддерживать их все.
эээ.... "кучу" — это ".NET windows only" и ".NET Core"? Ладно, пусть даже две. А они решили ту самую проблему Немерли, когда код выдавался только под платформу, где запускался компилятор?
VD> Даже у CCI есть проблемы. А у Cecil их еще больше
Хм... ладно, это не сильно важно, но API Cecil'а мне понравился больше. Изделия от MS — они мало того, что сильно упали в качестве со временем, так ещё несут на себе крест совместимости (старый код им, видители, жалко выкидывать). Я б на них не поставил.
VD> плюс в из кода Рослина можн узнать некоторые решения при генерации кода (которые не тривильны)
Влад, вы же сделали целый компилятор — неужели у MS опять остались "секреты правильного кода"?? Вроде ж и ECMA стандарт даже есть.
VD> так что изучение Roslyn-а по любому полезно. Плюс одно может быть кому-то интересно для самообразования (повышения скилов).
"Не слушайте советы по похудению от людей, толще вас". Я верю, что там могут быть зарыты жемчужины программизма, но ковыряться во всей этой куче от людей, не способных написать нормальную IDE — увольте. Да и язык(C#), как оказалось, пилят далеко не лучшие умы нашей галактики.
12 лет эти "специалисты" зрели до multiple return values, default parameter value, всё так же сидят на протухших итераторах (диапазоны рулят), а хорошей GUI'ни нет до сих пор. Можно выдвигать тысячи оправданий во всхлиппертоблогах, но настоящий инженер никогда не выпустит муйню — совесть не позволит.
VD>Ну, может у меня на моей колокольни глаз замылен и я вижу все не так как следует, но по-моему, я описал как раз те вопросы которые должны возникнуть у потенциальных разработчиков.
Т.е. смысл статьи — "побежали писать Немерлю"?? Не, Влад, там было что угодно, но только не это. Ты даёшь инфу, но не даёшь чётких указаний, задач. Есть только вкрапления "вот это не сделано", но чтобы за это взяться, нужны более подробные пояснения.
VD>Честно говоря все равно не понял в чем разница. Milestone — это и есть разжевывание.
Неа. Milestone — это "краткий план действий" для тех, кто уже в курсе — они там тупо ставят галочку "сделано".
Новичкам же нужен подробный план, вот как ты написал, только в самих пунктах должны быть явно указанные задачи, чтоб сразу был понятен контекст. Вплоть до указания классов, где нужно ковыряться.
K>>Кратко, вот в том списке стадий компиляции нужно пометить жирным, что Нитра должна делать за нас (всё, и сделанное, и планируемое), VD>Нитра — это инструмент. Она за нас ничего не делает. Она предоставляет средства реализации. Ну, как C# или C++. Чтобы понять, что она предоставляет лучше прочесть статьи по ней.
Ты говоришь формально правильный, но бесполезный текст. Нитра — это прежде всего недоделанный проект. Что в нём сделано — ты уже отметил, но в виде беседы за пивом: "В них сделано не всё, так что там есть над чем поработать" — вот так никто помогать не сядет.
Прямо в каждой стадии, которую ты описал, нужно дать чёткий список: DONE/TODO. Причём если задача крупная, разбивать до осознаваемых проблем. Это как большой план действий, состоящий из множества мелких задач.
VD>Можно по подробнее расписать этот и другие проекты. Но боюсь, что здесь детализация тоже же будет размывать картину.
Ровно наоборот — хорошая "общая картина" + внятные подробности в каждом пункте — прекрасная иллюстрация для новичков.
VD>Реализация языка программирования Mini C на Nitra
Вот сейчас только кончил читать. Кратко — это ужас. Ощущаю себя школьником, который пришёл на 1 курс, а ему за одну лекцию рассказали о кварках, позитронах и тут же непринуждённо набросали чертёж коллайдера. ЭТО НЕ РАБОТАЕТ.
МиниС — это всё равно БОЛЬШОЙ язык для того, чтобы въехать в Нитру. Но если с грамматикой (порождающей Parse Tree) я как-то более-менее разобрался, то мэппинг и связывание пролетели коллайдерным шумом мимо мозга. Вот сейчас я примерно такой:
Влад, по-моему сейчас слово "Нитро-всемогутер" начинает приобретать отрицательный смысл. Это та же самая ошибка, на которую напоролись космические архитекторы WPF'а — излишнее обобщение идей. Декларативность — это клёво, но только там, где есть статика, неизменность, никаких кастомизаций или "иногда другого поведения". Вот тот же мэпинг я бы тупо написал в коде — это куда очевиднее, чем учить крючкотворства ещё одного DSL'я. Он хоть и DSL, но он не особо упрощает проблему! Лучше для юзерского кода написать хелперы, упрощающие жизнь.
Другими словами, _я_бы_ пересмотрел концепцию Нитры и там, где DSL превращается в кашу всевозможных параметров и уточнений, сделал бы юзерский код — вот там пусть они и изгаляются.
VD>Честно говоря, по-моему, для того чтобы дело начало двигаться важно не понимание состояния проекта, а чтобы люди начали мне помогать.
Твоё видение порождает во мне такую картину: стоит Влад, перед ним куча брёвен и нечто, напоминающее взорванный блиндаж (будущий дом). На вопросы о размерах, чертежах, инструментах, Влад бросается к первому бревну и начинает куда-то вставлять, попутно призывая хватать остальные брёвна и тоже пристраивать. Это хуже вавилонской башни!
Влад, всё как раз наоборот — пока люди не поймут всей картины и чёткого понимания задачи, они не смогут ни за что взяться — это как бы очевидно даже кэпу.
Сначала нужно въехать в сам проект, в компиляторные стадии, модули, затем посмотреть на свои силёнки и меру интереса к конкретным задачам, а потом уже, осознав сложность конкретной задачи, браться за неё.
VD>Я уже несколько раз закидывал идею начала работы над языками, но все хлапали глазки и даже не вступали в дискуссию.
Сложность. Ты можешь быть гением, построившим прямо в мозге новую вселенную, но ты должен понимать — не только лишь все въедут в твои теории (которые, к слову, надо ещё уметь объяснить). Но даже имея ясное видение, ты не создашь ничего практического, если это будет чертовски сложно. Всё гениальное — просто. В Нитре я этой простоты не вижу. Подозреваю, другие — тоже. Плюс сюда сложность самой задачи как таковой.
Если Нитру можно упростить — упрощай, прялка с вёслами не взлетит.
VD>Даже скажу больше. Проблема в том, чтобы люди начали знакомиться с самой Нитрой.
Ну как видишь, в этот форум заходят люди! Значит сама идея им нравится. Но Нитра проста только на первых стадиях (да и там слегка наворочено), а дальнейшие описания просто убивают мозг.
По мне, так вообще "конструктор языков" — идея для кафедр и скучающих профессоров. Язык (если он гибкий и мощный) — он вообще ОДИН нужен.
Вот им Немерля и была. Но у Немерли был говённый каркас, что убивало перспективы развития. ВОТ ЕГО бы надо было переписать, отполировать синтаксис, добавить недостающие точки расширения и вуаля — ваяй себе макросы, да синтаксисы! Неужели что-то нужно помимо одного мощного Немерля??
VD>... на котором я убедился, что человек со стороны вполне может освоить Нитру.
Ну не... вот если бы он в полностью автономном режиме написал компилер по имеющимся докам — да, я б лично пожал руку. Но я уверен, вопросов были тонны и половина из них — "а как написать в грамматике, чтобы...". С подсказками я и "сопромат" сдать могу!
Я вот даже разжёванное "создание МиниС" прочёл — и то утонул в дебрях. Понятно, что каждая закорючка в коде — вещь нужная, но у вас там столько всего, что уже не помогает, а мешает думать прямолинейно.
VD> Но, к сожалнеию нет даже простого фитбэка.
Уже дал — сложность. Идя тропой автоматизации всего и вся, это неизбежность — ты просто вынужден делать сложный DSL, чтобы учесть все аспекты "реальных" языков (тут ещё аж с Питоном лезли). Да и честно, много кому нужны "конструкторы"? Грамматики, мэппинги — это скучно, люди хотят простые макросы — чтобы две строчки и бац — у тебя новый синтаксис!
K>>Ну вот, список стадий уже есть! Ты даже написал про уже сделанные модули, но они нужны в самом списке, а не подстрочником.
VD>Я не понимаю, что такое подстрочник. Включать их в сам список — это значит еще больше его раздувать.
Подстрочник — это сноски у книг. Зачем лазить в отдельный раздел, когда нужно прямо в списке? Да, раздувать, что с того? Жалко пикселей?
Этот список мне тем и понравился, что он хорошо обозревает работу компилера. Туда ещё б деталей и список работ — тогда это был бы удобный чуть ли не "учебник". Жалко места — сунь задачи под схлопывающуюся область.
K>>Вопрос не в тему: про объединении C+#x$% и Nemerle-2 ты упомянул, что "АСТ можно вынести в общий модуль" — это как и зачем??
VD>Ну, вот как-бы об этом я и писал. Вся первая часть этому и была посвящена. Но ты сказал, что это не важные детали, а выходит, что то ли не прочел, то ли не понял.
Я ж не Ломоносов — прочёл и всё понял! Да и судя по тому, что я понял, в модуль выносится не АСТ, а АСТ-классы! Точнее слова — лучше тебя понимают.
VD> На то он и абстракный, чтобы не зависит от конкретного языка.
Согласен, круто. Но опять см. замечание про количество языков. Мне бы и одного Немерля хватило бы до конца жизни. А Цешарп — тот пускай мелкософт пилит, всё равно никакого смысла бежать впереди них нет — они что запланировали, то и пилят (вместе с зарплатой ). Твои/наши революции им нафик не нужны — у них "интыпрайз", совместимость, костыли архитектуры... задолбали 12 лет тошнить по фиче в год.
Ну, я высказался, ты сам думай. Вокруг полно неглупых людей, но если даже им что-то мешает, пора в консерватории что-то менять.
Здравствуйте, VladD2, Вы писали:
VD>Честно говоря, по-моему, для того чтобы дело начало двигаться важно не понимание состояния проекта, а чтобы люди начали мне помогать. Другими словами, чтобы люди из созерцателей превратились в помошников — комьюнити развивающее язык.
VD>Я уже несколько раз закидывал идею начала работы над языками, но все хлапали глазки и даже не вступали в дискуссию. А когда дискуссия спонтанно завязалась на https://gitter.im/rsdn/nemerle, быстро выяснилось, что она перешла в обсуждение где найти по больше фич, которые желательно впихнуть в язык. Вот только я и сам знаю что можно впихнуть я язык. А проблема не в этом, а в том, чтобы начать этот язык равивать.
Тут такое дело. Ты фактически говоришь: "Пацаны помогите мне коллайдер построить. Сначала сделаем ускоритель, потом ловушку, ну ещё кабинка для сторожа нужна."
А надо говорить так: "Пацаны, мне электрощиток надо установить в 7 комплексе, параметры такие-то." Глядишь кто-нибудь и отзовётся.
Люди обычно не хотят брать на себя большую ответственность. Может стоит самому начать разработку, попутно составляя список конкретных небольших заданий с краткой инструкцией как к ним подступиться.
Здравствуйте, VladD2, Вы писали:
K>>Калькулятор. Самый ужасный, порочный и неправильный пример в области компиляторов
VD>Калькулятор — это классический пример.
Классический, но одинаково бестолковый в применении конкретно к компиляторам. Разбор выражений — да. Компиляторы — НЕТ! Через пример человек обязан прощупать узлы АСТ, генерацию кода. В калькуляторе ничего этого нет — тупо замена АСТ-узлов вычисляющими функциями. Это совсем не то, что должно быть в реальном проекте.
VD>А что тут рассказывать то? Без восстановления вся Nitra на фиг не нужна.
ггг Ну вот, я и спросил — какой именно профит даёт "восстановление в Нитре"? И что-то мне подсказывает, грамматика тоже должна быть слегка прогнута под "восстановление"?...
VD>Восстановление работает. Для жизни хватает.
Влад, ты не решай сгоряча, просто у меня тут крамольная мысль: Взять Нитру и использовать от неё только парсер (это, я так понял, улучшенный PEG?). Пишем на парсере Немерлю-2, попутно устраняя косяки и правильно реализуя расширение грамматики. Куча легаси кода никуда не пропадёт, просто придётся слегка обновить. Может даже натянуть синтаксис чуть ближе к C#. А далее пусть энтузазисты пилят свои расширения поверх удобного, компактного ядра!
Один конкретный язык пилить куда проще "языкового всемогутера". Тем более, что Немерля и является своеобразным конструктором — ты можешь вводить новый синтаксис! А классы — они везде классы.
Такой более приземлённый проект имеет куда большие шансы на завершение. Если расширить синтаксис может любой похапэшник, то возиться с целым конструктором компиляторов могут считанные единицы. Да и откровенно, какой коммерческой фирме нужен "лепитель языков"? Вот, индусофт — и те тянут ВАСИК чисто из маразма одного из боссов, единственный их полноценный язык — C#. А "многоязыковая платформа .NET" никому в пень не упёрлась — пара маргиналов струячат на F#, вот и вся "многоязыковость". Другими словами, "конструктор" не продашь, а вот язык — запросто!
А если к нему дописать IDE, написанную на нём же (без легаси-*овна от мелкософта), то вообще будет универсальный инструмент! (многие без IDE просто не будут даже смотреть на язык)
Иногда в долгой дороге нужно не упорство, а смелость признаться, что идёшь не туда и вовремя повернуть.
Здравствуйте, ionoy, Вы писали:
I>Тут такое дело. Ты фактически говоришь: "Пацаны помогите мне коллайдер построить. Сначала сделаем ускоритель, потом ловушку, ну ещё кабинка для сторожа нужна." I>А надо говорить так: "Пацаны, мне электрощиток надо установить в 7 комплексе, параметры такие-то." Глядишь кто-нибудь и отзовётся.
Тут хоть мытьем, хоть катаньем, все ничего не делается.
Я бы еще понял, если бы кто-то что-то хотел сделать, обратился ко мне и не смог. Но просто дальше трепа ни у кого ничего не идет. Один орел 3 подхода делал, но после получения примитивнейшего задания исчезал на неопределенное время не задавая ни одного вопроса.
Ты на своем опыте понимаешь, что любые вопросы можно было решить обращаясь ко мне.
Был еще Кириченко. Он даже сваял Мини С. Но потом тоже пропал.
В общем, работа сложная. Это не просто побалываться. Тут надо разбираться. Тратить много времени.
Вот ты бы или Хардейс смогли бы внести свой вклад. Но вам в лом. У вас свои задачи/"игрушки" есть. Я как бы даже могу вас понять, но мне то от этого не легче.
Авторы Немерла тоже им занимались пока учились в универе и пока у них был грант от МС. А как нашли работу — забили на свое детище. Один в гугле черти чем занимается, другой в МС над занудным верификатором для С работает.
I>Люди обычно не хотят брать на себя большую ответственность. Может стоит самому начать разработку, попутно составляя список конкретных небольших заданий с краткой инструкцией как к ним подступиться.
Да ни вопрос. Был бы хоть кто-то вызвавшийся помогать. Задачку любой сложности придумаем за 5 минут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я бы еще понял, если бы кто-то что-то хотел сделать
Хочу сделать Немерле 1.5 — обычный, расширяемый компилятор единственного языка. Пусть код 1.0 придётся выкинуть — не жалко. Новый код будет на парсере от Нитры и свободным от ограничений Немерле 1.0;
Ну и чем это не проект?
Здравствуйте, Kolesiki, Вы писали:
K>Хочу сделать Немерле 1.5 — обычный, расширяемый компилятор единственного языка. Пусть код 1.0 придётся выкинуть — не жалко. Новый код будет на парсере от Нитры и свободным от ограничений Немерле 1.0; K>Ну и чем это не проект?
Нет. Это баловства. Шансов у тебя сделать что-то путное нет. Не то что бы мало, а просто нет.
Для того чтобы разработать язык такой сложности:
1. Нужен не хилоый опыт в разработке ЯП.
2. Нужно понимать какие проблемы были у Nemerle 1.x.
3. Нужны соответствующие средства разработки и базовые библиотеки/фреймворки или большой штат сотрудников работающих на фул-тайм и соответствющее руководство и планирование.
4. Наконец нужны те кто будет этим заниматься. Потому как при закате солнца вручную (при попытке написать с нуля) потребуется много человеколет. Поляки (авторы Nemerle) писали Nemerle около трех лет. Над проектом никогда не работало меньше двух человек. Они срезали все углы с целью как можно быстрее добежать до работающего прототипа, но все же не смоли сделать быстрее. И это при том, что опыт у них был.
Так что идея пытаться создать параллельный проект не просто глупа, а даже вредна. В таких проектах силы распылять нельзя.
Если у тебя есть задор и азарт, лучше приложи свою руку к основному проекту, а не трать его почем зря.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ionoy, Вы писали:
I>>Тут такое дело. Ты фактически говоришь: "Пацаны помогите мне коллайдер построить. Сначала сделаем ускоритель, потом ловушку, ну ещё кабинка для сторожа нужна." I>>А надо говорить так: "Пацаны, мне электрощиток надо установить в 7 комплексе, параметры такие-то." Глядишь кто-нибудь и отзовётся.
VD>Тут хоть мытьем, хоть катаньем, все ничего не делается.
VD>Я бы еще понял, если бы кто-то что-то хотел сделать, обратился ко мне и не смог. Но просто дальше трепа ни у кого ничего не идет. Один орел 3 подхода делал, но после получения примитивнейшего задания исчезал на неопределенное время не задавая ни одного вопроса.
Проблема, Влад, в том, что никому не интересно решать твои проблемы, сорри за каламбур. В случае Nitra всё ещё усугбляется сложностью задач, что отсекает всякую школоту. Как правило, люди которые участвуют в чужих Open Source проектах делают это не ради фана, а для решения каких-то своих задач.
Мне, например, Nitra кажется весьма перспективным продуктом, однако в текущем виде я его для решения своих задач использовать не могу даже теоретически. А в отрыве от практических задач мне эта тема не настолько интересна, чтобы глубоко погружаться в сложную предметную область и тратить на это свое личное время.
Что мне было бы интересно (и чем я мог бы потенциально заняться): порт на Java и интеграция с Eclipse, вместо VS. Другими словами, мне нужен XText, только на стероидах — прежде всего с поддержкой модульных грамматик.
Здравствуйте, #AVM, Вы писали:
AVM>Что мне было бы интересно (и чем я мог бы потенциально заняться): порт на Java и интеграция с Eclipse, вместо VS. Другими словами, мне нужен XText, только на стероидах — прежде всего с поддержкой модульных грамматик.
Тебе нужна нитра написанная на яве или нитра которая может интегрироваться в Eclipse и генерировать код на яве?
Второе намного проще.
Интеграция в Eclipse скорее всего просто механическая работа.
Генерация кода на яве в основном упирается в библиотеку, которая может читать и писать пакеты явы. Я не знаю есть ли такие под .НЕТ.
Как вариант можно генерировать текст на яве и компилировать его ява компилятором.
Для того чтобы саму нитру научить компилировать себя в яву придётся проделать весьма большой объём работы.
Нужно полностью забутстрапить нитру. Что само по себе не просто.
Только после этого можно начать думать о переводе нитры на другие платформы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, #AVM, Вы писали:
AVM>>Что мне было бы интересно (и чем я мог бы потенциально заняться): порт на Java и интеграция с Eclipse, вместо VS. Другими словами, мне нужен XText, только на стероидах — прежде всего с поддержкой модульных грамматик. WH>Тебе нужна нитра написанная на яве или нитра которая может интегрироваться в Eclipse и генерировать код на яве? WH>Второе намного проще. WH>Интеграция в Eclipse скорее всего просто механическая работа. WH>Генерация кода на яве в основном упирается в библиотеку, которая может читать и писать пакеты явы. Я не знаю есть ли такие под .НЕТ. WH>Как вариант можно генерировать текст на яве и компилировать его ява компилятором.
WH>Для того чтобы саму нитру научить компилировать себя в яву придётся проделать весьма большой объём работы. WH>Нужно полностью забутстрапить нитру. Что само по себе не просто. WH>Только после этого можно начать думать о переводе нитры на другие платформы.
Мне нужен полный тулчейн компилятора на Java, кроме бэкенда. Парсер, AST, типизация, генерация плагинов для Eclipse. Интеграция самой нитры с Eclipse тоже конечно не помешает, но это точно не первый приоритет.
Под портом на Java я скорее имел ввиду более-менее механическое переписывание с Nemerle на Java. Я понимаю, что бутстраппинг — это конечно более правильный путь, но с учетом того, с какой скоростью продвигаются работы по Nitra, ждать мне этого ещё долго. Впрочем, если ты готов время от времени консультировать — то я может и впрягся бы сам в это дело.
Только учитывай, что я в этой предметной области разбираюсь довольно поверхностно, так что вопросы могут быть несколько ламерские.
Генерацию я на первых порах делал бы в Java-исходники, так кажется проще, а производительность на этом этапе не так важна.
Здравствуйте, #AVM, Вы писали:
AVM>Мне нужен полный тулчейн компилятора на Java, кроме бэкенда. Парсер, AST, типизация, генерация плагинов для Eclipse.
Я так толком и не понял тебе нужен компилятор на яве или генерация кода на яве?
Ибо для того чтобы генерировать код на яве компилятор не обязан быть на яве.
Единственное чем за это придётся заплатить это поставить .НЕТ или моно на машине разработчика и билдсервере.
На машину клиента ни нитру ни компилятор сгенерированный нитрой ни .НЕТ или моно тащить не нужно.
Я конечно могу представить ситуацию, когда компилятор должен быть непременно на яве. Но скорей всего это не так.
AVM>Интеграция самой нитры с Eclipse тоже конечно не помешает, но это точно не первый приоритет.
Это одно и тоже.
Нитра уже частично написана на нитре. Так что если сделать одно то второе заработает сразу.
Для того чтобы встроить нитру и компиляторы которые генерирует нитра в Eclipse ни нитру ни компиляторы генерируемые нитрой на яву переводить не нужно.
Вся поддержка ИДЕ живёт в отдельном процессе. Для VS это тоже актуально, ибо она 32хбитная и в её адресное пространство загружается куча всякой хрени. Так что адресного пространства на всех не хватает.
Благодаря этому на яве нужно написать только очень тонкую прокладку, которая будет работать вот с этим протоколом. https://github.com/rsdn/nitra/blob/master/Nitra/ClientServer/Nitra.ClientServer.Messages/Messages.n
Для простоты и надёжности нужно модифицировать макросы немерела которые генерируют код на .НЕТ для работы с этим протоколом так чтобы они ещё и генерировали код на яве. https://github.com/rsdn/nitra/tree/master/Nitra/ClientServer/Nitra.ClientServer.Macros
Имея этот код реализация плагина к Eclipse должна быть тривиальной. Если конечно разработчики Eclipse не создали проблем на ровном месте. Но API плагинов Eclipse я не видел так что судить не берусь.
AVM>Под портом на Java я скорее имел ввиду более-менее механическое переписывание с Nemerle на Java.
Не реально. Совсем, совсем не реально. Даже не думай про это.
Для того чтобы это сделать нужно несколько человеко-лет.
И потом будет отдельная проблема с синхронизацией двух проектов.
AVM>Я понимаю, что бутстраппинг — это конечно более правильный путь, но с учетом того, с какой скоростью продвигаются работы по Nitra, ждать мне этого ещё долго. Впрочем, если ты готов время от времени консультировать — то я может и впрягся бы сам в это дело.
И я и Влад проконсультируем тебя в любой момент.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, #AVM, Вы писали:
AVM>>Мне нужен полный тулчейн компилятора на Java, кроме бэкенда. Парсер, AST, типизация, генерация плагинов для Eclipse. WH>Я так толком и не понял тебе нужен компилятор на яве или генерация кода на яве? WH>Ибо для того чтобы генерировать код на яве компилятор не обязан быть на яве. WH>Единственное чем за это придётся заплатить это поставить .НЕТ или моно на машине разработчика и билдсервере. WH>На машину клиента ни нитру ни компилятор сгенерированный нитрой ни .НЕТ или моно тащить не нужно. WH>Я конечно могу представить ситуацию, когда компилятор должен быть непременно на яве. Но скорей всего это не так.
Мне конечно нужен именно компилятор, написанный на Java. Извиняюсь, что недостаточно четко выразил свою мысль.
Влад, а вы не рассматриваете вариант снова поработать по найму? На тех же где-то условиях, как в JetBrains — выделенная команда, занимающаяся Nitra и, возможно, другими языковыми технологиями?
Здравствуйте, #AVM, Вы писали:
AVM>Влад, а вы не рассматриваете вариант снова поработать по найму? На тех же где-то условиях, как в JetBrains — выделенная команда, занимающаяся Nitra и, возможно, другими языковыми технологиями?
Рассматриваем. А кто платить будет?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, #AVM, Вы писали:
AVM>>Влад, а вы не рассматриваете вариант снова поработать по найму? На тех же где-то условиях, как в JetBrains — выделенная команда, занимающаяся Nitra и, возможно, другими языковыми технологиями? WH>Рассматриваем. А кто платить будет?
Детали предлагаю обсуждать в Skype: andrew.v.moiseev
Здравствуйте, #AVM, Вы писали:
AVM>Влад, а вы не рассматриваете вариант снова поработать по найму? На тех же где-то условиях, как в JetBrains — выделенная команда, занимающаяся Nitra и, возможно, другими языковыми технологиями?
Мысли такие есть. Я планировал кое что доделать (для более презентабельного вида) к зиме/осени и пройтись по софтовым фирмам.
Но без связей изнутри, конечно, будет не прос.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если сравнить nitra и xtext, что в nitra есть нового и полезного?
Еще не нашел тулкита для java, не дадите ссылку, если конечно таковой существует (то что должен существовать следует из того, что разрабатывалось оно в jetbrains).
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Если сравнить nitra и xtext, что в nitra есть нового и полезного?
1. Модульность.
2. Расширяемость. В том числе в рантайме. Например, как Немерле, путем открытия пространства имен в некотором файле можно добавить поддержку расширения языка.
3. Безлексерность позволяет более гибко расширять языки. Меньше конфликтов. Нет проблем с тем, что в разных местах языка нужны разные лексерные контексты.
3. Нитра может поддерживать более сложные языки с меньшим объемом ручного кодирования.
4. Поддержка вывода типов.
xtext работает по верх генерированного АНТЛР 3 парсера. Отсюда и все проблемы с модульностью.
LP>Еще не нашел тулкита для java, не дадите ссылку, если конечно таковой существует (то что должен существовать следует из того, что разрабатывалось оно в jetbrains).
Реализации для Явы нет. Для этого нужно финасирвоание. Это довольно большой объем работ. Хотя мы все спроектировали так, чтобы это можно было сделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
САД>>а зачем оно всё нужно, когда есть scala? САД>>я просто не совсем в курсе. С>
С>Покажите мне, пожалуйста, аналог linq2db для Scala. До сих пор ведь не написали. И не напишут, потому что язык жуткий, хуже C++.
С>Вот например, оператор <|*|> С>Угадайте-ка, что он означает. С>https://stackoverflow.com/questions/2545248/function-syntax-puzzler-in-scalaz\
в scala linq не нужен. там множество вещей делается значительно проще. без изобретений велосипедов.
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>в scala linq не нужен. там множество вещей делается значительно проще. без изобретений велосипедов.
Так, вы не поняли, о чём речь. linq2db — это типизированный SQL. Запросы к базе вы будете писать либо руками, либо как-то выводить из кода, с контролем компилятора, с оптимизациями, с безопасной параметризацией и т.п. И вот второго варианта — не-руками, в scala просто нет. Есть scala slick, и порождает он совершенно монстроидальные запросы, пользоваться им нельзя.
Вот так вот — язык вроде бы мощный, а чего надо — на нём не пишут.
САД>>в scala linq не нужен. там множество вещей делается значительно проще. без изобретений велосипедов. С>Так, вы не поняли, о чём речь. linq2db — это типизированный SQL. Запросы к базе вы будете писать либо руками, либо как-то выводить из кода, с контролем компилятора, с оптимизациями, с безопасной параметризацией и т.п. И вот второго варианта — не-руками, в scala просто нет. Есть scala slick, и порождает он совершенно монстроидальные запросы, пользоваться им нельзя.
типизированные запросы тоже не всегда нужны.
или не всегда возможны. как например с dapper.
linq2db всё равно не убережет тебя от ошибок в рантайме.
а получить типизированный результат позволяет и scala
С>Вот так вот — язык вроде бы мощный, а чего надо — на нём не пишут.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LaPerouse, Вы писали:
VD>3. Безлексерность позволяет более гибко расширять языки. Меньше конфликтов. Нет проблем с тем, что в разных местах языка нужны разные лексерные контексты.
А бэктрекинга нет? Как в DCG Prolog-а. Наличие бэктрекинга позволит выйти за пределы контекстно-свободных грамматик.
VD>3. Нитра может поддерживать более сложные языки с меньшим объемом ручного кодирования. VD>4. Поддержка вывода типов.
LP>>Еще не нашел тулкита для java, не дадите ссылку, если конечно таковой существует (то что должен существовать следует из того, что разрабатывалось оно в jetbrains).
VD>Реализации для Явы нет. Для этого нужно финасирвоание. Это довольно большой объем работ. Хотя мы все спроектировали так, чтобы это можно было сделать.
Понятно. А не проще попробовать генерировать ява-код из уже сгенерированного .net кода?
Социализм — это власть трудящихся и централизованная плановая экономика.
