Здравствуйте, WolfHound, Вы писали:
WH>Не парсеры, а кодогенераторы. И не расширением чего-то там, а должны генерировать код в один бекенд.

Пусть есть паскаль, немерле, с, лисп, с# и бак джабаскрипт, нет, ллвм. Как будет идти генерация

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

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

_C_>Редактирование AST было бы неплохо разрешить через какой-то вменяемый API.

Редактирования АСТ просто не будет. С огромной вероятностью можно утверждать, что вообще не придется работать с АСТ вручную. Вся обработка будет идти через ДСЛ-и.

VD>>Сообщения об ошибках будут выдавать на основе сканирования АСТ.

_C_>У пользовательского кода должна быть возможность самому распутать эту ситуацию.

Какую? Неоднозначность, есть неоднозначность.

Да и не будет никакого пользовательского кода. Будет декларативное описание. Он не распутыать будет, а указывать как интерпретировать. А уж распутывать все будет сгенерированный по ДСЛ-ю код.

_C_>Как документ-презентация он непонятно кому адресован. Догадаться можно что Н-программистам. Но он как бы не для них, ибо говорит о том, как здорово будет создавать другие языки.

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

_C_>неужто Scala собрались эмулировать? вот это был бы ход — Одерски ошалел бы от удивления.

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

_C_>Идея многоязычности компилятора имеет немного смысла, когда мы на .net или java rte. А вот конвертация в другой язык — было бы дельно и интересно.

Конвертация тоже возможна. Компилятор не обязан порождать бинарники. Это может быть и код на другом языке. Можно сделать бэкнд генерирующий С и какой-нить файл с метаданными открытого формата. Проблема будет только в поддержке GC (если язык в нем нуждается).

_C_>Но об этом нигде не говорится.

Значит добавлю. Обо всем не упомнишь.

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

_C_>Пробовал. на плюсах, питоне, бу.

Ага. Но в итоге пришел к нам . Значит не очень удобно это было делать.

_C_>Но даже почитав и посмотрев на код-примеры в новом парсере очевидных достоинств в описании грамматики и логике не улавливаю.
_C_>они наверняка есть. о них имеет смысл написать.

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

VD>>Вообще, забавно слышать такие слова от автора довольно крутого ДСЛ-я.
VD>>Твой движок БД ни что иное как ДСЛ!

_C_>мой движок должен по идее генерить весь код от одной строки-аттрибута в рутовом классе сохраняемой иерархии.
_C_>а DSL — это от безысходности (RemoveParsedField где?).

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

В прочем, думаю и решение на основе "одного атрибута" будет сделать на Н2 довольно просто.

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

А>Этот момент не ясен. Вот пример.как будет идти генерация для языков немерле,с, с#, паскаль в бак нет, ллвм, джабаскрипт

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

Или, скажем, не знает жабаскрипт типов. Его уже в бэкнд дотнета не скомпилишь. А если скомпилишь, то эмуляция будет старшная и совместимость опять таки пострадает.

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

А>Как связан язык и бак? Если есть 5 языков и 3 бака то надо делать 15 генераторов?

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

WH>>А в случае с питоном и лиспом и решать то нечего. Оба динамически типизированные.
А>Вообще то есть компиляторы и первого и второго.

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

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Этот момент не ясен. Вот пример.как будет идти генерация для языков немерле,с, с#, паскаль в бак нет, ллвм, джабаскрипт

VD>Бэкэнд подразумевает не только генератор исполнимого файла, но и сериализатор и считыватель метаданных. Очевидно, что если не озаботиться предоставлением метаданных, то языки будут слабо совместимы даже, если будут поддерживать единый бэкэнд. Скажем не знает С классов. Ничего не поделаешь. С без расширений не соможет воспользоваться классами описанными в Немерле.

VD>Или, скажем, не знает жабаскрипт типов. Его уже в бэкнд дотнета не скомпилишь. А если скомпилишь, то эмуляция будет старшная и совместимость опять таки пострадает.

Слепой с глухим. Будет ли промежуточное представление или будет будет необходимость описывать все возможные трансформации? Каким будет промежуточное представление если оно будет?

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

VD>А так, ну, создай и для питона типизированное расширение.

Получится, практически, Boo

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

А>Слепой с глухим.

Это, типа, наезд?

А>Будет ли промежуточное представление или будет будет необходимость описывать все возможные трансформации?

Да, будет. И скорее всего не одно. Но его можно будет использовать, а можно не использовать. Мы не принуждаем к этому.

А>Каким будет промежуточное представление если оно будет?

Скажем для дотнета будет нечто вроде типизированного АСТ немерла. В нем минимум констуркций, никакой расширяемости и все однозначно.

При трансляции можно будет разбирать исходное АСТ (содержащее информацию о типах) с помощью паттерн-матчинга и квази-цитат (их поддержка будет генерироваться по декларативному описанию).

VD>Редактирования АСТ просто не будет. С огромной вероятностью можно утверждать, что вообще не придется работать с АСТ вручную. Вся обработка будет идти через ДСЛ-и.

Звучит непонятно. Если речь идет о спец DSL бэкенда разве что. но опять же где-то я кусок кода поймаю и захочу трансформировать — он в AST будет.
запретить не удастся.

_C_>>неужто Scala собрались эмулировать? вот это был бы ход — Одерски ошалел бы от удивления.
VD>Нам не надо будет ее эмулировать. Только описать и смастерить для ней бэкэнд. Причем смастерив бэкнд к Яве мы и другие языки на Яве сможем запускать.

Если ты в этом уверен, то реально имеет смысл получить заказ от Одерски и ко смастерить задешево Scala компилятор на .Net.
Языки то близкие. И компилятора у них путного для .Net не придвидится. мелкософт только на словах заинтересована в скале. ессно, такая махина.
переедет F-шарпик, не кашлянув ни разу. заодно дернуть у них вывод типов, если он круче.

VD>В прочем, думаю и решение на основе "одного атрибута" будет сделать на Н2 довольно просто.

как бы это важно. вообще практические задачи важнее теоретических. но это понимаешь с годами. и с трудом.

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

_C_>Звучит непонятно. Если речь идет о спец DSL бэкенда разве что. но опять же где-то я кусок кода поймаю и захочу трансформировать — он в AST будет.
_C_>запретить не удастся.

Дык мы тебе не дадим поймать.

Если серьезно, то работать с АСТ ты будешь с помощью квази-цитат. А лезть а уровень типов из которых он состоит не придется.

Менять его тоже не нужно вручную. Будешь описывать процедуру трансформации, и получать на выходе измененный код. Но это не будет изменение по месту.

_C_>Если ты в этом уверен, то реально имеет смысл получить заказ от Одерски и ко смастерить задешево Scala компилятор на .Net.

Ну, вот когда будет Н2, то можно будет об этом подумать. А пока это слишком дорого, а у Одесски денег нет. Он на студентах паразитирует .

_C_>Языки то близкие. И компилятора у них путного для .Net не придвидится. мелкософт только на словах заинтересована в скале. ессно, такая махина.

+1

_C_>переедет F-шарпик, не кашлянув ни разу. заодно дернуть у них вывод типов, если он круче.

Наш круче, но они даже смотреть не хотят.

VD>>В прочем, думаю и решение на основе "одного атрибута" будет сделать на Н2 довольно просто.

_C_>как бы это важно. вообще практические задачи важнее теоретических. но это понимаешь с годами. и с трудом.

Я с этим не спорю. Мы кто-то, но точно не теоретики. Просто мы хотим сделать Н как того бы следовало (с учетом современных знаний).

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

VD>Исходный Разор считает все, кроме включаемых фрагментов ЯП, текстом.

Это твое личное заблуждение. И я уже сто раз тебе об этом говорил.

Попробуй скомпилировать такой кусок:

@foreach (var i in new[] { 1 })
{
    <text>
        @i
        </i>
    </text>
}

Причем еще до рейзора я тебе говорил о том, что совсем не обязательно строить дерево в рантайме для того, чтобы обеспечить корректность разметки. Но проверку корректности надо делать очень интеллектуальной (чтобы она не била по рукам в штатных случаях) либо минимальной (там где ошибка очевидна). Авторы рейзора пошли по второму пути, они оставили только самые простые проверки, что сильно дешевле и минимизирует количество WTF разработчиков. Которые, в массе своей, не любят, чтобы их загоняли в светлое будущее палками.

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

VD>Вопросы и критика очень приветствуются.

Хотелось бы увидеть пояснения по поводу того, как примерно будет выглядеть создание компилятора C++ с помощью N2, и не окажутся ли трудозатраты на это больше, чем на написание компилятора С++ с нуля на том же С или C++. И каким окажется быстродействие компилятора созданного таким путём. Не окажется ли N2 недостаточно гибким для описания всех тонкостей грамматики и правил разрешения имён C++. Каким образом, например, будут описываться правила инстанциации шаблонов? Будут ли после этого автоматически работать подсказки и автодополнение в IDE внутри шаблонов, или придётся прикладывать для этого значительные усилия (опять-таки, желательно сравнение с реализацией этого с нуля без помощи N2)? Насколько легко можно будет написать полноценные рефакторинги Rename или Extract/Inline Method (с автоматическим разрешением конфликтов) для C++, реализованного с помощью N2?

Типизация. Будет ли привязка к системе типов .NET или можно будет, например, описать (декларативно?) систему типов Haskell со всякими GADTs, rank-N, existentials, type families и functional dependencies?

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

ME>>и вообще, я не вижу особого смысла делать DSL-довески над *синтаксисом* c++
ME>>вот, скажем, сконвертить с++ в какой-то приличный синтаксис и там поднавесить DSL-довески — это реально
VD>Мы не собираемся делать С++-парсеры. Но сделать это будет возможно и относительно не сложно. В прочем, может быть сделаем парсер С++ просто в качестве теста и чтобы подразнить всех тех кто считает, что это невозможно.
Разбирать С++ без семантического анализа невозможно. А для семантического анализа придётся поддерживать кучу фич полноценного компилятора.

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


А>>Каким будет промежуточное представление если оно будет?

VD>Скажем для дотнета будет нечто вроде типизированного АСТ немерла. В нем минимум констуркций, никакой расширяемости и все однозначно.

VD>При трансляции можно будет разбирать исходное АСТ (содержащее информацию о типах) с помощью паттерн-матчинга и квази-цитат (их поддержка будет генерироваться по декларативному описанию).

Вообщем тумана еще больше. Есть фортран. Его надо транслировать в ллвм и надо транслировать в нет. Фронт как я понимаю будет одинаковым. Дальше как будет идти? Причем по обеим ветвям.

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

VD>* О том как из Н2 можно извлечь выгоду (монетизировать).

Я вот не уверен, были ли здесь уже дискуссии на эту тему, но мне очень любопытно. Я с огромным сочувствием отношусь к Nemerle, даже чуток выучил. К тому же я — эсперантист, это по-своему "Nemerle среди натуральных языков"

У меня есть кой-какая власть в выборе технологий, и в принципе работаю в довольно DSL'ных областях, казалось бы вот оно. Но, по-моему, главная проблема в монетизации — как-то уж больно мала роль собственно программирования в задаче разработки программного продукта. Т.е. основные сложности лежат в области коммуникации, осознании требований, учёте деталей, выработки "языка проекта", придумывании/выборе алгоритмов. Эти же факторы поддерживают "неэффективные" языки.

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

N>У меня есть кой-какая власть в выборе технологий, и в принципе работаю в довольно DSL'ных областях, казалось бы вот оно. Но, по-моему, главная проблема в монетизации — как-то уж больно мала роль собственно программирования в задаче разработки программного продукта. Т.е. основные сложности лежат в области коммуникации, осознании требований, учёте деталей, выработки "языка проекта", придумывании/выборе алгоритмов. Эти же факторы поддерживают "неэффективные" языки.

Одно из главных преимущество ДСЛ-ного подхода заключается в том, что он позволяет пробовать алгоритмы решения задачи не меняя реализации.

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

При работе над тем же генератором парсеров Вольфхаунд уже несколько раз изменил внутреннею реализацию, а ДСЛ изменился не так значительно (поправить грамматику можно за 10 минут).

На задачах где решение не очевидно с самого начала — это дает определенную свободу.

Кроме того сама выработка ДСЛ-я приводит к осмысливанию предметной области.

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

К тому же задачи бывают разные. В некоторых объем кодирования настолько велик, а цена ошибки высока, что использование метапрограммирвоания является безусловным преимуществом.

Просто надо освоить этот подход и применить его пару раз на практике.

Лично у меня все сомнения исчезли после первого применения.

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

А>Вообщем тумана еще больше. Есть фортран. Его надо транслировать в ллвм и надо транслировать в нет. Фронт как я понимаю будет одинаковым. Дальше как будет идти? Причем по обеим ветвям.

Это зависит от ряда деталей.

Могут быть следующие варианты:
1. (пессимистический) Нет ни бэкэндов, ни кода трансляции в них. Тогда придется писать оба бэкэнда и код трансляции в них. При этом можно постараться использовать промежуточный язык имеющийся для других бэкэндов, да и код других бэкндов (хотя в последнем случае процент повторного использования будет не велик).

2. Имеются подходящие бэкэнды, но нет трансляции в них и нет общего низкоуровнего языка. Тогда нужно написать
две трансляции в каждый из бэкэндов, или создавать промежуточный язык и транслировать с него + делать одну трансляцию промежуточного языка бэкнд.

3. (оптимистический) Имеется низкоуровневый промежуточный язык для которого уже написана трансляция в оба бэкнда. Тогда надо всего лишь написать трансляцию из АСТ (точнее это дерево разбора) в этот промежуточный зык.

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

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

VD>Здравствуйте, Аноним, Вы писали:

А>>Вообщем тумана еще больше. Есть фортран. Его надо транслировать в ллвм и надо транслировать в нет. Фронт как я понимаю будет одинаковым. Дальше как будет идти? Причем по обеим ветвям.

VD>Это зависит от ряда деталей.

VD>Могут быть следующие варианты:
VD>1. (пессимистический) Нет ни бэкэндов, ни кода трансляции в них. Тогда придется писать оба бэкэнда и код трансляции в них. При этом можно постараться использовать промежуточный язык имеющийся для других бэкэндов, да и код других бэкндов (хотя в последнем случае процент повторного использования будет не велик).

VD>2. Имеются подходящие бэкэнды, но нет трансляции в них и нет общего низкоуровнего языка. Тогда нужно написать
VD>две трансляции в каждый из бэкэндов, или создавать промежуточный язык и транслировать с него + делать одну трансляцию промежуточного языка бэкнд.

VD>3. (оптимистический) Имеется низкоуровневый промежуточный язык для которого уже написана трансляция в оба бэкнда. Тогда надо всего лишь написать трансляцию из АСТ (точнее это дерево разбора) в этот промежуточный зык.

VD>Да, забыл упомянуть. Кроме трасляции в бэкэнд еще нужно чтобы язык был совместим с метаданными предоставляемыми бэкэдом или написать конвертер метаданных. Метаданные описывают типы, методы, атрибуты и другую фигню которая есть в языке. Скажем у Хаскеля не будет наследования и классов, но будут классы типов, модули и т.п. Если бэкнд не поддерживает классов типов, то их придется эмулировать на основе имеющихся примитивов (или бэкэнд не подойдет).

Стало яснее. Спасибо. Добавь плз это и блок-схему(подсистемы и кто кого посылает от кого зависит) в драфт. Станет намного лучше и понятнее. Еще раз спасибо.

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

N>Хотелось бы увидеть пояснения по поводу того, как примерно будет выглядеть создание компилятора C++ с помощью N2, и не окажутся ли трудозатраты на это больше, чем на написание компилятора С++ с нуля на том же С или C++. И каким окажется быстродействие компилятора созданного таким путём. Не окажется ли N2 недостаточно гибким для описания всех тонкостей грамматики и правил разрешения имён C++. Каким образом, например, будут описываться правила инстанциации шаблонов? Будут ли после этого автоматически работать подсказки и автодополнение в IDE внутри шаблонов, или придётся прикладывать для этого значительные усилия (опять-таки, желательно сравнение с реализацией этого с нуля без помощи N2)? Насколько легко можно будет написать полноценные рефакторинги Rename или Extract/Inline Method (с автоматическим разрешением конфликтов) для C++, реализованного с помощью N2?

Думаю, что если я скажу — "да, можно..." ты мне все равно не поверишь . Реальным ответом на твои вопросы будет реализация (хотя бы тестовая) поддержки С++.

Откровенно говоря С++ или Хаскель нам не очень интересен (по понятным причинам). Мы задумывали Н2 несколько для другого. Но раз уж решено делать универсальное решение, то можно попробовать поднять и их.

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

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

N>Типизация. Будет ли привязка к системе типов .NET

К дотнету мы решили не привязваться. Общая идея такая. На бэкэнд будет возложена обязанность чтения и записи метаданных (если это нужно для языка) и представление их в форме объектов. Не знаю получится ли сделать это декларативно. Посмотрим.

Подсистема типизации будет работать с ними через некий ДСЛ который позволяет описывать зависимости типов и т.п. При этом то как это будет воздействовать на метаданные будет определяться генератором кода и библиотеками. Их (генератор и библиотеки) мы планируем сделать сменными.

Это позволит описывать метаинформацию в виде необходимом для конкретного языка.

N>или можно будет, например, описать (декларативно?) систему типов Haskell со всякими GADTs, rank-N, existentials, type families и functional dependencies?

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

В общем, тут важно понять, что основным элементом абстракции в Н2 будет не ООП, ФП, полиморфизм и т.п., а кодогенераторы и ДСЛ-и. ДСЛ-и позволят скрыть детали, а кодогенераторы предоставить нужную, для конкретных языков, функциональность.

В общем, еще раз предлагаю тебе помочь и сделать модули для С++ и Хаскеля. Ну, и будем благодарны, за идеи и критику. В скором времени я выложу примерное описание технических подробностей. Ждем критику по ним.

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

Z>Это твое личное заблуждение. И я уже сто раз тебе об этом говорил.

Да ты много всего гворишь. Если на все это обращать внимание, то можно впасть в депрессию .

Z>Попробуй скомпилировать такой кусок:

Z>

Z>@foreach (var i in new[] { 1 })
Z>{
Z>    <text>
Z>        @i
Z>        </i>
Z>    </text>
Z>}
Z>

Попробовал. Компиляция прошла успешно. Еще вопросы?

Ты видимо полагаешь, что раз IDE подсвечивает теги, то их и компилятор не пропустит. Вот только это не так.

Разор — это тупой текстуальный препроцессор. Я тебе уже раз сто сказал, что интеллекта в нем — 0 целых хрен десятых, но ты споришь.

Z>Причем еще до рейзора я тебе говорил о том, что совсем не обязательно строить дерево в рантайме для того, чтобы обеспечить корректность разметки.

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

В общем, тут это полный офтоп. Предлагаю закрыть тему. Для Н2 совершенно все равно как ты будешь реализовывать свой ДСЛ. Он предназначен для реализации любых ДСЛ-ей.

Z>Авторы рейзора пошли по второму пути, они оставили только самые простые проверки, что сильно дешевле и минимизирует количество WTF разработчиков.

Ты несешь ахинею. Разор — это тупо текстовый прероцессор. Такой же тупой как АСТ.НЕТ. Вся разница с АСП.НЕТ только в том как они выделяют участки кода. Через 10 лет существования АСП.НЕТ в МС решили, таки, использоват для этого полноценный парсер, а не регекспы. Охринительное новаторство! Молись дальше на них.

Z>Которые, в массе своей, не любят, чтобы их загоняли в светлое будущее палками.

Тебя никто не загоняет. Каменный молоток остался в целости и сохранности.

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

А>Стало яснее. Спасибо. Добавь плз это и блок-схему(подсистемы и кто кого посылает от кого зависит) в драфт. Станет намного лучше и понятнее. Еще раз спасибо.

ОК. Что-нибудь придумаем.