Планирую дополнить это дело:
* Гипотетическими примерами кода.
* Подробнее рассказать о принципах реализации тех или иных вещей.
* Рассуждениями о том какие продукты можно делать на базе Н2 и с кем/чем они могут конкурировать.
* О том как из Н2 можно извлечь выгоду (монетизировать).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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?
.
VD>Вопросы и критика очень приветствуются.
Да особо не покритикуешь.
Пока всё супер кратко, человеку не в теме понять о чём идёт речь будет практически нереально.
Tom>>Интересно можно ли будет на основе фреймворка построить парсер скажем С++-а? WH>Можно, но сложно. Я сейчас думаю, как это сделать. WH>Дело в том что в С++ есть откровенно контекстно-зависимые конструкции. WH>Например: WH>a < b > c; WH>Может быть объявлением переменной или выражением с двумя сравнениями. WH>Таким образом, чтобы это разобрать нужно, знать, что такое a и b. WH>А для этого на уровне парсера нужно иметь таблицу символов.
WH>К чему я в конце концов приду пока не ясно.
парсер с++ это скорее неподъемная задачка для одного человека
т.к. если хочется парсить с++, то надо брать clang и делать из него выхлоп
Здравствуйте, Аноним, Вы писали:
WH>>А в случае с питоном и лиспом и решать то нечего. Оба динамически типизированные. А>Вообще то есть компиляторы и первого и второго.
Комплируемость и динамическая типизация вещи ортогональные. C# с dynamic тоже динамически типизируем
Здравствуйте, VladD2, Вы писали:
ME>>и вообще, я не вижу особого смысла делать DSL-довески над *синтаксисом* c++ ME>>вот, скажем, сконвертить с++ в какой-то приличный синтаксис и там поднавесить DSL-довески — это реально VD>Мы не собираемся делать С++-парсеры. Но сделать это будет возможно и относительно не сложно. В прочем, может быть сделаем парсер С++ просто в качестве теста и чтобы подразнить всех тех кто считает, что это невозможно.
Разбирать С++ без семантического анализа невозможно. А для семантического анализа придётся поддерживать кучу фич полноценного компилятора.
.
VD>Вопросы и критика очень приветствуются.
VD>Планирую дополнить это дело: VD>* Гипотетическими примерами кода. VD>* Подробнее рассказать о принципах реализации тех или иных вещей. VD>* Рассуждениями о том какие продукты можно делать на базе Н2 и с кем/чем они могут конкурировать. VD>* О том как из Н2 можно извлечь выгоду (монетизировать).
Прочитав драфт задумался о бреде сивокобыльном. Если бы это написал не Влад2 то точно разочаровался в языке. ПРИМЕРЫ
Re[3]: [draft] N2 – языковый фрeймворк
От:
Аноним
Дата:
22.03.12 10:57
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>написаны сложно и непонятны. Буду признателен за конструктивную критику предлагающую пути увеличения доходчивости моих слов.
Сейчас есть рыба, пока не будет наполнения конструктивная критика софична
.
VD>>Вопросы и критика очень приветствуются. Tom>Да особо не покритикуешь. Tom>Пока всё супер кратко, человеку не в теме понять о чём идёт речь будет практически нереально.
А вообще оно конечно выглядит оч. многообещающим.
Интересно можно ли будет на основе фреймворка построить парсер скажем С++-а? Или тогоже RAZOR-а?
Приветствуются вопросы по существу и критика конкретных слов. То что это пока никуда не годится я знаю и так.
Мне нужна критика. Не бойтесь показаться глупым. Тема довольно сложна для описания. Мне очень важно, чтобы в итоге текст стал понятным. По этому чем больше вопросов и критики будет, тем лучше.
Подчеркну, что здесь пока что описывается не язык (он будет реализован поверх Н2-фрэймворка), а решение позволяющее создать любой язык (компилятор и средства поддержки), в том числе и следующую версию Н.
По возможности, будьте конструктивны. Критикуя указывайте конкретику, а еще лучше предлагайте свои решения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
Tom>Пока всё супер кратко, человеку не в теме понять о чём идёт речь будет практически нереально.
ОК. Хочешь сказать, что получилось слишком сложно и туманно?
Буду думать как сделать тему более доходчивой. Над примерами буду работать сегодня.
И все же хотелось бы получить критику/вопросы по конкретным частям. Возможно, если осмысливать все не в целом, а частями, то будет проще.
ЗЫ
Приношу свои извинения всем тем, кто не понял написанного. Тема довольно сложная Много метауровней получается. Как изложить ее просто я пока не понимаю. Но так как это все равно нужно, то давайте работать над понятностью вместе.
Можно попробовать в режиме вопрос-ответ, а я отражу эти вопросы в следующей версии "бумаги".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вопросы.
Базовая виртуальная машина, базовые типы?
Парсер? ll, lr?
Как будут разрешаться конфликты расширяемых грамматик? Точки расширения с ограничениями грамматики? Как правильно их описать?
Как будет "джунгли из многоствольных деревьев" проецироваться в однозначное "дерево"?
Более практичный вопрос на закуску: как будут передаваться значения из модуля с своей грамматикой и структурой данных в другой модуль с другой структурой данных? Например: как передать "красное-черное дерево" из питон-модуля в лисп-модуль?
Re[2]: [draft] N2 – языковый фрeймворк
От:
Аноним
Дата:
22.03.12 12:00
Оценка:
Здравствуйте, VladD2, Вы писали:
Каким будут подсистемы, как они взаимосвязаны(рисунок).
Примеры куском для каждой подсистемы. Если с парсером более менее понятно, то с остальными.
Какими ограничениями будет обладать, что будет невозможно сделать и почему.
Оптимизации кода, где они будут сосредоточены/распределены?
Будет ли возможность реализовать С++, Перл, Руби (или их подмножество)и почему нет. Насколько упроститься/усложниться при этом работа.
Здравствуйте, fin_81, Вы писали:
_>Более практичный вопрос на закуску: как будут передаваться значения из модуля с своей грамматикой и структурой данных в другой модуль с другой структурой данных? Например: как передать "красное-черное дерево" из питон-модуля в лисп-модуль?
Эта задача не может иметь общего решения, все грамматики так или иначе будут использовать те структуры данных, которые будут доступны для выбранного backend.
Здравствуйте, Tom, Вы писали:
Tom>Интересно можно ли будет на основе фреймворка построить парсер скажем С++-а?
Можно, но сложно. Я сейчас думаю, как это сделать.
Дело в том что в С++ есть откровенно контекстно-зависимые конструкции.
Например:
a < b > c;
Может быть объявлением переменной или выражением с двумя сравнениями.
Таким образом, чтобы это разобрать нужно, знать, что такое a и b.
А для этого на уровне парсера нужно иметь таблицу символов.
К чему я в конце концов приду пока не ясно.
Tom>Или тогоже RAZOR-а?
Это не проблема.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, fin_81, Вы писали:
_>Вопросы. _>Базовая виртуальная машина, базовые типы?
Это будет универсальный всемогутор который может компилировать что угодно в что попало.
Так что фиксированной ВМ или базовых типов не будет.
Какой бекенд выберешь в такой, и будет транслироваться твой код.
Ессно нужно понимать, что не для любого языка можно будет использовать любой бекенд.
_>Парсер? ll, lr?
Ни то ни другое. https://github.com/rampelstinskin/ParserGenerator
_>Как будут разрешаться конфликты расширяемых грамматик?
Вот так: Re[2]: Обновление ParserGenerator'а
Возможно, будут добавлены приоритеты для правил на случай если это правило не сработает.
Но я пока не могу представить случай, когда это правило даст сбой.
_>Точки расширения с ограничениями грамматики? Как правильно их описать?
Чего?
_>Как будет "джунгли из многоствольных деревьев" проецироваться в однозначное "дерево"?
А зачем джунгли? Джунгли это комбинаторный взрыв и куча неоднозначностей на ровном месте. Смотри мое сообщение про правило разрешения конфликтов.
И что характерно любой разобранный вариант можно типизировать.
_>Более практичный вопрос на закуску: как будут передаваться значения из модуля с своей грамматикой и структурой данных в другой модуль с другой структурой данных? Например: как передать "красное-черное дерево" из питон-модуля в лисп-модуль?
Языки должны быть совместимы на уровне бекенда.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
VD>ОК. Хочешь сказать, что получилось слишком сложно и туманно?
кому надо, тот поймет. Непонятно, почему за бортом остались динамические и полудинамические языки. игнорите?
типы и их расчет — планируется ли возможность глобальной калькуляция типов, а то боюсь F# надо вычеркнуть, как и многие другие.
перехват и восстановление после ошибок из макроса, когда есть возможность что-то подправить/уточнить — языковой фреймворк должен уметь.
о тех, кому не надо.
вообще непонятна цель этой работы. есть готовые компиляторы с отличной поддержкой и фаршем, на кой кому то делать это снова.
позиционирование работы ,- для кого, никак не ясно. DSL можно писать в десятке других сред. чем лучше? а можно не морочится с DSL-ями
а чуть подправить настройку для N или для K? что мне даст создание своего DSL кроме головной боли?
VD>"Работая над Nemerle нами (группой RSDN) было выявлено несколько архитектурных и множество проектных недостатков Nemerle."
Это несерьезно. Почему за столько лет не устранили? Компилятор написан для заявленного функционала и со своей ролью справляется.
Tom>>Или тогоже RAZOR-а? WH>Это не проблема.
Так у него же тоже как я понимаю очень не тривиальный парсер? Надо как то отделять куски разметки от кода?
Здравствуйте, Tom, Вы писали:
Tom>Интересно можно ли будет на основе фреймворка построить парсер скажем С++-а? Или тогоже RAZOR-а?
Конечно, можно. И не только парсер.
Разор вообще задача довольно простая (при наличии парсера встроенного языка (например, шарпа)). С С++ придется повозиться. Все же не самый простой язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Можно, но сложно.
Да ладно преувеличивать то.
WH>Я сейчас думаю, как это сделать. WH>Дело в том что в С++ есть откровенно контекстно-зависимые конструкции. WH>Например: WH>a < b > c; WH>Может быть объявлением переменной или выражением с двумя сравнениями. WH>Таким образом, чтобы это разобрать нужно, знать, что такое a и b. WH>А для этого на уровне парсера нужно иметь таблицу символов.
Вот именно. Иметь таблицу символов и средство проверки символов на принадлежность к типам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
Tom>>>Или тогоже RAZOR-а? WH>>Это не проблема. Tom>Так у него же тоже как я понимаю очень не тривиальный парсер? Надо как то отделять куски разметки от кода?
У него довольно тривиальный парсер.
Исходный Разор считает все, кроме включаемых фрагментов ЯП, текстом.
Мы можем даже более сложный парсер сделать. Он будет разбирать иерархию состоящую из тегов и включаемых выражений. Примерно так делает Решарпер. Только они создают два дерева, а мы будем работать в два приема. На первом будем парсить исходный язык (смесь тегов и ЯП), а уже на втором этапе переписывать его в код на ЯП.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, fin_81, Вы писали:
WH>Это будет универсальный всемогутор который может компилировать что угодно в что попало. WH>Так что фиксированной ВМ или базовых типов не будет. WH>Какой бекенд выберешь в такой, и будет транслироваться твой код. WH>Ессно нужно понимать, что не для любого языка можно будет использовать любой бекенд.
То есть нет ни ВМ, ни базой структуры АСТ, ни парсера. Мне лень писать на этом фреймворке что-нибудь практичное, так как все придется делать самому: ВМ, под него АСТ, под АСТ писать парсер.
_>>Парсер? ll, lr? WH>Ни то ни другое. WH>https://github.com/rampelstinskin/ParserGenerator
Содержательно, а главное всем понятно.
[offtop]Мне русский язык более понятен, хотя и не родной. Я русский до 10 лет можно сказать практически не знал [/offtop]
_>>Как будут разрешаться конфликты расширяемых грамматик? WH>Вот так: WH>Re[2]: Обновление ParserGenerator'а
WH>Возможно, будут добавлены приоритеты для правил на случай если это правило не сработает. WH>Но я пока не могу представить случай, когда это правило даст сбой.
Так и не понял как разрешаются. Первое предположение — приоритеты. Приоритеты — это магические цифры и их лучше собирать в одном месте и хорошо комментировать. Как-то это плохо соотносится с подключаемыми самописными модулями.
_>>Точки расширения с ограничениями грамматики? Как правильно их описать? WH>Чего?
Например можно сделать основной скелет языка, в который можно встраивать "выражения", и точка расширения для своих "выражений" может быть описан ограниченным шаблоном грамматики, в котором не могут быть конструкции из основного скелета. Как эти шаблоны описывать?
_>>Как будет "джунгли из многоствольных деревьев" проецироваться в однозначное "дерево"? WH>А зачем джунгли? Джунгли это комбинаторный взрыв и куча неоднозначностей на ровном месте. Смотри мое сообщение про правило разрешения конфликтов. WH>И что характерно любой разобранный вариант можно типизировать.
Никак не ограниченные расширения породят этот лес. И надо придумать инструмент разрешающий эти конфликты: алгоритмы слияния, разрешения неоднозначности интерактивными инструментами и тп.
_>>Более практичный вопрос на закуску: как будут передаваться значения из модуля с своей грамматикой и структурой данных в другой модуль с другой структурой данных? Например: как передать "красное-черное дерево" из питон-модуля в лисп-модуль? WH>Языки должны быть совместимы на уровне бекенда.
Предположим оба языка и лисп и питон компилируются под один бекенд, например язык СИ. Как мне передать из питона в лисп последовательность-тупл, так чтобы на лиспе можно было бы обойти все элементы map'ом? Это кстати важный момент при работе со со всякими дсл'ями — взаимодействие основной программы с этим дсл.
Здравствуйте, fin_81, Вы писали:
_>То есть нет ни ВМ, ни базой структуры АСТ, ни парсера. Мне лень писать на этом фреймворке что-нибудь практичное, так как все придется делать самому: ВМ, под него АСТ, под АСТ писать парсер.
Не правильно.
Будет несколько языков и бекендов в стандартной поставке.
WH>>https://github.com/rampelstinskin/ParserGenerator _>Содержательно, а главное всем понятно.
Это новый алгоритм описание, которого пока не существует в природе.
_>Так и не понял как разрешаются.
Что конкретно не ясно?
_>Первое предположение — приоритеты. Приоритеты — это магические цифры и их лучше собирать в одном месте и хорошо комментировать. Как-то это плохо соотносится с подключаемыми самописными модулями.
Это не приоритеты, а сила связывания. И цифры там временно.
_>Например можно сделать основной скелет языка, в который можно встраивать "выражения", и точка расширения для своих "выражений" может быть описан ограниченным шаблоном грамматики, в котором не могут быть конструкции из основного скелета. Как эти шаблоны описывать?
Ничего не понял.
_>Никак не ограниченные расширения породят этот лес. И надо придумать инструмент разрешающий эти конфликты: алгоритмы слияния, разрешения неоднозначности интерактивными инструментами и тп.
Не породят. Парсер однозначный. Если конечно кто-то специально не создать два идентичных правила.
_>Предположим оба языка и лисп и питон компилируются под один бекенд, например язык СИ. Как мне передать из питона в лисп последовательность-тупл, так чтобы на лиспе можно было бы обойти все элементы map'ом? Это кстати важный момент при работе со со всякими дсл'ями — взаимодействие основной программы с этим дсл.
Это решаемая проблема. Конкретики у меня пока нет.
А в случае с питоном и лиспом и решать то нечего. Оба динамически типизированные.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: [draft] N2 – языковый фрeймворк
От:
Аноним
Дата:
22.03.12 15:21
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, fin_81, Вы писали:
_>>То есть нет ни ВМ, ни базой структуры АСТ, ни парсера. Мне лень писать на этом фреймворке что-нибудь практичное, так как все придется делать самому: ВМ, под него АСТ, под АСТ писать парсер. WH>Не правильно. WH>Будет несколько языков и бекендов в стандартной поставке.
Как связан язык и бак? Если есть 5 языков и 3 бака то надо делать 15 генераторов?
WH>А в случае с питоном и лиспом и решать то нечего. Оба динамически типизированные.
Вообще то есть компиляторы и первого и второго.
Re[7]: [draft] N2 – языковый фрeймворк
От:
Аноним
Дата:
22.03.12 15:33
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Аноним, Вы писали:
WH>>>А в случае с питоном и лиспом и решать то нечего. Оба динамически типизированные. А>>Вообще то есть компиляторы и первого и второго.
H>Комплируемость и динамическая типизация вещи ортогональные. C# с dynamic тоже динамически типизируем
вообще то я о лиспе с статической типизацией. Есть и такое.
Здравствуйте, WolfHound, Вы писали:
_>>Первое предположение — приоритеты. Приоритеты — это магические цифры и их лучше собирать в одном месте и хорошо комментировать. Как-то это плохо соотносится с подключаемыми самописными модулями. WH>Это не приоритеты, а сила связывания. И цифры там временно.
Сила связывания — что это такое? Что будет вместо магических чисел.
_>>Никак не ограниченные расширения породят этот лес. И надо придумать инструмент разрешающий эти конфликты: алгоритмы слияния, разрешения неоднозначности интерактивными инструментами и тп. WH>Не породят. Парсер однозначный. Если конечно кто-то специально не создать два идентичных правила.
Парсер то может быть и однозначный (доказательства?), но контекстно свободные грамматики в общем случае неоднозначны, и любят порождать "лес многоствольных деревьев", при этом этот лес может быть однозначным по смыслу. И любая помощь в разрешении этого — это очень хорошо для разработчика.
Как разрешить эту в общем то однозначную грамматику без использования приоритетов, ассоциативности и тп. Эти правила написаны в разных модулях расширяющих грамматику, поэтому сложно синхронизировать эти магические числа-приоритеты.
_>>Предположим оба языка и лисп и питон компилируются под один бекенд, например язык СИ. Как мне передать из питона в лисп последовательность-тупл, так чтобы на лиспе можно было бы обойти все элементы map'ом? Это кстати важный момент при работе со со всякими дсл'ями — взаимодействие основной программы с этим дсл. WH>Это решаемая проблема. Конкретики у меня пока нет. WH>А в случае с питоном и лиспом и решать то нечего. Оба динамически типизированные.
Только при одном условии, что парсеры этих языков являются расширением общего для этих языков базы-скелета парсеров, с общими базовыми типами. Иначе придется писать свою сериализацию, маршалинг и тп.
Здравствуйте, _Claus_, Вы писали:
_C_>кому надо, тот поймет. Непонятно, почему за бортом остались динамические и полудинамические языки. игнорите?
Акцент делается на статике. Из статики динамику всегда можно сделать. Так что, думаю, динамику тоже можно будет делать.
_C_> типы и их расчет — планируется ли возможность глобальной калькуляция типов, а то боюсь F# надо вычеркнуть, как и многие другие.
Планируем. Там бинома Ньютона нет. Просто придется использовать более примитивные, но более шустрые алгоритмы используемые в F#-е.
_C_>перехват и восстановление после ошибок из макроса, когда есть возможность что-то подправить/уточнить — языковой фреймворк должен уметь.
Как раз сейчас Вольфхаунд работает над проблемой восстановления после обнаружения ошибок парсинга.
Генерируемый Н2 парсер будет парсить все, включая ошибочный код. Н2 сам будет генерировать АСТ и в это АСТ заранее будут включаться ветки для представления ошибочного кода (в виде строк).
Так что, конечный АСТ будет содержать внутри ветки с ошибками, если ошибки были в исходном коде. Тоже самое будет и с типизацией.
В случае, если компилятор не сможет однозначно идентифицировать констуркцию, в АСТ будет помещены все возможные варианты для этой конструкции.
Сообщения об ошибках будут выдавать на основе сканирования АСТ.
_C_>о тех, кому не надо.
?
_C_>вообще непонятна цель этой работы. есть готовые компиляторы с отличной поддержкой и фаршем, на кой кому то делать это снова.
Хорошая поддержках есть у двух-трех языков. Так что надо это всем остальным. Например, для той же Скалы до сих пор нет качественной поддержки IDE, а компилятор ее вызывает много нареканий по скорости.
Мы начали работу над этим проектом с целью создать новую версию Немерла. Обдумав все мы пришли к выводу, что для качественно реализации Н нам все равно потребуется подобный фрэймворк. А раз такой фрэмворк будет, то на его основе можно делать и другие языки.
Так же это важно для возможной коммерциализации нашего решения. Чтобы язык завоевал популярность нужно приложить массу усилий, потратить море денег и т.п.
По сему кроме расширяемого языка мы будем предлагать языковый фрэймворк и (самое главное) реализованные на базе этого фрэймворка языки. Так мы можем создать интеграцию к IDE и компилятор для C#, VB, Скалы, F# и т.п.
Любой язык воспроизведенный на базе этой платформы будет получать все преимущества этой платформы, и будет совместим с другими языками реализованными на этой платформе.
_C_>позиционирование работы ,- для кого, никак не ясно. DSL можно писать в десятке других сред. чем лучше?
Иди попробуй напиши. Проблема ДСЛ-подхода в том, что ДСЛ-и очень сложно создавать. В большинстве случаев люди взвесив за и против отказываются от этой идеи ввиду сложности реализации.
Мы же предоставим охринительно высокоуровневое решение которое сделает реализацию забавой.
_C_>а можно не морочится с DSL-ями а чуть подправить настройку для N или для K? что мне даст создание своего DSL кроме головной боли?
Даст возможность решать задачи проще, быстрее и эффективнее. Сам Н2 будет делаться на ДСЛ-ном подходе. Я уже вижу невероятные преимущества от этого.
Вообще, забавно слышать такие слова от автора довольно крутого ДСЛ-я.
Твой движок БД ни что иное как ДСЛ!
VD>>"Работая над Nemerle нами (группой RSDN) было выявлено несколько архитектурных и множество проектных недостатков Nemerle." _C_>Это несерьезно. Почему за столько лет не устранили? Компилятор написан для заявленного функционала и со своей ролью справляется.
Потому что они серьезные. Их устранение сравнимо с написанием того самого с нуля.
Потом есть кодовая база которая уже зафиксировала некоторые ошибочные решения. Если изменить алгоритмы, то посыпется эта база.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, fin_81, Вы писали:
_>Сила связывания — что это такое?
Мой алгоритм это совмещение PEG и вот этого алгоритма. http://publications.csail.mit.edu/lcs/specpub.php?id=715
Собственно сила связывания это binding power описанная в этом алгоритме.
Плюс несколько своих доработок напильником.
_>Что будет вместо магических чисел.
Каждая сила связывания получит свое имя.
И порядок относительно других сил связывания.
_>Парсер то может быть и однозначный (доказательства?),
Он так построен.
_>но контекстно свободные грамматики в общем случае неоднозначны,
Я в курсе. Но у меня парсер разбирает не КС грамматики.
Так что мимо.
Более того я считаю все попытки построить парсер по КС грамматике глупостью.
Ибо КС грамматика описывает не разбор, а генерацию текста.
А я работаю именно с разбирающей, а не генерирующей грамматикой.
Поэтому у меня и нет неоднозначностей.
_>Как разрешить эту в общем то однозначную грамматику без использования приоритетов, ассоциативности и тп.
Вот сила связывания эти проблемы прекрасно решает.
_>Эти правила написаны в разных модулях расширяющих грамматику, поэтому сложно синхронизировать эти магические числа-приоритеты.
Так их в конечной версии и не будет.
_>Только при одном условии, что парсеры этих языков являются расширением общего для этих языков базы-скелета парсеров, с общими базовыми типами. Иначе придется писать свою сериализацию, маршалинг и тп.
Не парсеры, а кодогенераторы. И не расширением чего-то там, а должны генерировать код в один бекенд.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, fin_81, Вы писали:
_>Базовая виртуальная машина,
Первая реализация самого Н2 будет на дотнете. Сам Н2 будет способен создавать компиляторы для любых платформ, в том числе и не основанных на виртуальных машинах. Например, можно будет просто генерировать код на С по полученному типизированному представлению.
_>базовые типы?
Свое внутреннее представление. Постараемся чтобы оно было максимально гибким, расширяемым. Так чтобы можно было охватить системы типов в основных популярных языках.
Типы для данного фрэймворка не более чем метаданные. Вопросы поддержки их в рантайме мы возлагаем на плечи тех кто будет делать бэкэнды и рантйм для этих языков.
_>Парсер? ll, lr?
Свой безлексерный гибрид. Алогритм основан на рекурсивный спуск с откатами в сочетании с Top Down Operator Precedence (TDOP) автором которого является Vaughan Pratt.
Его особенности:
1. Безлексерность (терминальные правила интегрируются в микро-парсеры).
2. Тотальная расширяемость. Правило просто помечается как расширяемое и его можно будет расширять из других модулей. Причем подключить расширяющие модули можно на лету, так что на базе этого дела можно реализовать Nemerle или шаблонизаторы вроде Разора.
_>Как будут разрешаться конфликты расширяемых грамматик?
Там хитрый алогоритм в котором побеждате более длинное правило имеющие более длинный разбор терминальных правил. Подробности у Вольфхаунда. Авторство алгоритма его.
Плюс должны быть еще какие-то механизмы разрешения конфликтов, но тут опять же лучше к Вольфхаунду.
_>Точки расширения с ограничениями грамматики? Как правильно их описать?
Очень просто. Описываешь имя правила без тела:
[StartRule, Ast()]
expr : Ast;
А расширения через "is". Расширения можно описывать в том же или в отдельном модуле (в том числе и в другой сборке).
[Ast(l, expr, r)] rounds is expr = '('s expr ')'s;
[Ast(l, expr, r)] seq is expr = '{'s expr* '}'s;
[Ast(num)] num is expr = number s;
[Ast(op, expr)] neg is expr = '-'s expr : 100;
[Ast(op, expr)] prefixDec is expr = "--"s expr : 200;
[Ast(expr, op)] postfixDec is expr = expr : 200 "--"s;
[Ast(l, op, r)] add is expr = expr : 10 '+'s expr : 10;
[Ast(l, op, r)] sub is expr = expr : 10 '-'s expr : 10;
[Ast(l, op, r)] mul is expr = expr : 20 '*'s expr : 20;
[Ast(l, op, r)] div is expr = expr : 20 '/'s expr : 20;
[Ast(l, op, r)] mod is expr = expr : 20 '%'s expr : 20;
[Ast(l, op, r)] pow is expr = expr : 31 '^'s expr : 30;
* Показан синтаксис используемый сейчас в генераторе парсеров. В Н2 он будет отличаться. Но для данного вопроса это не так важно.
_>Как будет "джунгли из многоствольных деревьев" проецироваться в однозначное "дерево"?
Для каждой ветки АСТ предполагается задавать описание типов. По этому описанию будет генерироваться код заполняющий специальные атрибуты. В случае неоднозначных конструкций в этих атрибутах будут помещаться списки неоднозначных котсорукций. Далее будет производиться попытка разрешения неоднозначности. В случае успеха значение атрибутов будет заменяться на однозначный результат. В случае неудачи будет выдаваться сообщение об ошибке, а в атрибуте будет оставаться список неоднозначностей.
_>Более практичный вопрос на закуску: как будут передаваться значения из модуля с своей грамматикой и структурой данных в другой модуль с другой структурой данных? Например: как передать "красное-черное дерево" из питон-модуля в лисп-модуль?
Это зависит от реализации бэкэндов этих языков. Если они совместимые, то подключении модуля (библиотеки) созданного на одном языке к другому будет происходить чтение метаданных и формироваться объект описывающий тип. Далее после типизации и прочей обработки бэкэнд будет генерировать обращение к членам этого типа. Если, опять таки, бэкэды совместимы, будет сгенерирован код ссылающийся на другой модуль и использующий конертный тип из него.
Так, например, для всех языков имеющих бэкэнд для дотнета или явы — это будет возможно.
В общем, мы оставляем этот вопрос разработчикам бэкэндов. Принципиальная возможность межъязыковой работы будет. А совместимы ли форматы метаданных у разных языков — это вопрос к авторам языков и бэкэндов к ним. Если бэкэнд не сможет использовать метаданные загруженные бэкэндом другого языка, или бэкэд не сможет использовать эти метаданные для генерации кода, то предать тип не получится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>В случае, если компилятор не сможет однозначно идентифицировать констуркцию, в АСТ будет помещены все возможные варианты для этой конструкции.
Редактирование AST было бы неплохо разрешить через какой-то вменяемый API.
VD>Сообщения об ошибках будут выдавать на основе сканирования АСТ.
У пользовательского кода должна быть возможность самому распутать эту ситуацию.
_C_>>о тех, кому не надо.
VD>?
Как документ-презентация он непонятно кому адресован. Догадаться можно что Н-программистам. Но он как бы не для них, ибо говорит о том, как здорово будет создавать другие языки.
_C_>>вообще непонятна цель этой работы. есть готовые компиляторы с отличной поддержкой и фаршем, на кой кому то делать это снова. VD>Хорошая поддержках есть у двух-трех языков. Так что надо это всем остальным. Например, для той же Скалы до сих пор нет качественной поддержки IDE, а компилятор ее вызывает много нареканий по скорости.
неужто Scala собрались эмулировать? вот это был бы ход — Одерски ошалел бы от удивления.
VD>Любой язык воспроизведенный на базе этой платформы будет получать все преимущества этой платформы, и будет совместим с другими языками реализованными на этой платформе.
Идея многоязычности компилятора имеет немного смысла, когда мы на .net или java rte. А вот конвертация в другой язык — было бы дельно и интересно.
Но об этом нигде не говорится.
_C_>>позиционирование работы ,- для кого, никак не ясно. DSL можно писать в десятке других сред. чем лучше? VD>Иди попробуй напиши. Проблема ДСЛ-подхода в том, что ДСЛ-и очень сложно создавать. В большинстве случаев люди взвесив за и против отказываются от этой идеи ввиду сложности реализации.
Пробовал. на плюсах, питоне, бу. Но даже почитав и посмотрев на код-примеры в новом парсере очевидных достоинств в описании грамматики и логике не улавливаю.
они наверняка есть. о них имеет смысл написать.
VD>Мы же предоставим охринительно высокоуровневое решение которое сделает реализацию забавой.
_C_>>а можно не морочится с DSL-ями а чуть подправить настройку для N или для K? что мне даст создание своего DSL кроме головной боли?
VD>Даст возможность решать задачи проще, быстрее и эффективнее. Сам Н2 будет делаться на ДСЛ-ном подходе. Я уже вижу невероятные преимущества от этого.
VD>Вообще, забавно слышать такие слова от автора довольно крутого ДСЛ-я. VD>Твой движок БД ни что иное как ДСЛ!
мой движок должен по идее генерить весь код от одной строки-аттрибута в рутовом классе сохраняемой иерархии.
а DSL — это от безысходности (RemoveParsedField где?).
Здравствуйте, m.e., Вы писали:
ME>и вообще, я не вижу особого смысла делать DSL-довески над *синтаксисом* c++ ME>вот, скажем, сконвертить с++ в какой-то приличный синтаксис и там поднавесить DSL-довески — это реально
Мы не собираемся делать С++-парсеры. Но сделать это будет возможно и относительно не сложно. В прочем, может быть сделаем парсер С++ просто в качестве теста и чтобы подразнить всех тех кто считает, что это невозможно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Каким будут подсистемы, как они взаимосвязаны(рисунок).
Что понимается под "подсистемами"?
А>Примеры куском для каждой подсистемы. Если с парсером более менее понятно, то с остальными.
В ближайшее время покажу парсер, области видимости и вычисляемые атрибуты.
А>Какими ограничениями будет обладать, что будет невозможно сделать и почему.
Перечислять невозможное можно бесконечно.
А>Оптимизации кода, где они будут сосредоточены/распределены?
В бэкэндах.
А>Будет ли возможность реализовать С++, Перл, Руби (или их подмножество)и почему нет.
Будет.
А>Насколько упроститься/усложниться при этом работа.
Все что связано с разбором и типизацией (проверки корректности, выявления типов, разрешением неоднозначностей) будет выполняться автоматически на основании декларативных описаний. Соответственно работа в этой части будет упрощена до предела. Фактически будет требоваться создать формальную спецификацию, а весь код будет сгенерирован автоматом.
В области преобразования полученного верхнеуровневого, типизированного представления в исполнимые файлы, то здесь придется попотеть. Мы будем предоставлять средства трансформации из одного языка в другой и низкоуровневые языки в которые можно будет относительно не сложно преобразовать свой язык. Ну, а из этих низкоуровневых языков в бинарное представление преобразование будет происходить автоматом (т.е. будет написано нами или кем-то со стороны).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, fin_81, Вы писали:
_>То есть нет ни ВМ, ни базой структуры АСТ, ни парсера.
Ага. И это супер круто!
_>Мне лень писать на этом фреймворке что-нибудь практичное, так как все придется делать самому: ВМ, под него АСТ, под АСТ писать парсер.
Неверный вывод. То что нет "базой структуры АСТ, ни парсера" не означает, что их нужно писать вручную.
Вместо них есть ДСЛ-и для их описания. И возможность использования готовых решений (импорт и расширение модулей).
Парсер будет генерироваться для каждого языкового модуля по декларативному описанию (смесь грамматики, описания типизации и т.п.).
_>Так и не понял как разрешаются. Первое предположение — приоритеты. Приоритеты — это магические цифры и их лучше собирать в одном месте и хорошо комментировать. Как-то это плохо соотносится с подключаемыми самописными модулями.
Гугли на тему Top Down Operator Precedence (TDOP, он же Pratt-парсер). Описаний мало, но они есть.
_>Например можно сделать основной скелет языка, в который можно встраивать "выражения", и точка расширения для своих "выражений" может быть описан ограниченным шаблоном грамматики, в котором не могут быть конструкции из основного скелета. Как эти шаблоны описывать?
Можно. Объявляешь любой правило расширяемым и расширяй его сколько угодно. Например, если есть правило Expression и тебе надо сделать правило MyExpression расширяющее его ты можешь написать нечто такое:
MyExpression is Expression = "my-prefix" MyRule;
MyRule : MyAst; // свое расширяемое правило
_>Никак не ограниченные расширения породят этот лес. И надо придумать инструмент разрешающий эти конфликты: алгоритмы слияния, разрешения неоднозначности интерактивными инструментами и тп.
Это какая-то научная фантастика основанная на голом теоретизировании.
На практике люди не пишут бездумных расширений.
В случае, если два расширения спарсят строку совершенно одинаковым образом, то будет выдано сообщение о неоднозначности. Иначе одно из правил победит и будет использовано, а другое отброшено.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [draft] N2 – языковый фрeймворк
От:
Аноним
Дата:
22.03.12 20:09
Оценка:
Здравствуйте, WolfHound, Вы писали: WH>Не парсеры, а кодогенераторы. И не расширением чего-то там, а должны генерировать код в один бекенд.
Этот момент не ясен. Вот пример.как будет идти генерация для языков немерле,с, с#, паскаль в бак нет, ллвм, джабаскрипт
Здравствуйте, Аноним, Вы писали:
А>вообще то я о лиспе с статической типизацией. Есть и такое.
Вообще-то в стандарт CL типизация вроде как не входит. Или я что-то путаю?
А так, ну, создай и для питона типизированное расширение.
Ответ же на твой вопрос прост. Если языки будут реализовывающий под единый бэкэнд и при этом будет ставиться задача добиться совместимости, то добиться этого будет можно.
Нужно будет, только, сделать так, чтобы оба языка понимали метаданные друг друга. Имея единый бэкэнд этого будет не сложно добиться.
Проблема будет только, если в понятиях одного языка нет понятий другого.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [draft] N2 – языковый фрeймворк
От:
Аноним
Дата:
22.03.12 20:18
Оценка:
Здравствуйте, 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>>А в случае с питоном и лиспом и решать то нечего. Оба динамически типизированные. А>Вообще то есть компиляторы и первого и второго.
Компилирующие только подмножество языка для которого можно статически вывести типы, или надмножество для которого типы задаются явно. Причем результат не очень в любом случае. Впрочем, это уже другая история.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [draft] N2 – языковый фрeймворк
От:
Аноним
Дата:
22.03.12 20:51
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
А>>Этот момент не ясен. Вот пример.как будет идти генерация для языков немерле,с, с#, паскаль в бак нет, ллвм, джабаскрипт
VD>Бэкэнд подразумевает не только генератор исполнимого файла, но и сериализатор и считыватель метаданных. Очевидно, что если не озаботиться предоставлением метаданных, то языки будут слабо совместимы даже, если будут поддерживать единый бэкэнд. Скажем не знает С классов. Ничего не поделаешь. С без расширений не соможет воспользоваться классами описанными в Немерле.
VD>Или, скажем, не знает жабаскрипт типов. Его уже в бэкнд дотнета не скомпилишь. А если скомпилишь, то эмуляция будет старшная и совместимость опять таки пострадает.
Слепой с глухим. Будет ли промежуточное представление или будет будет необходимость описывать все возможные трансформации? Каким будет промежуточное представление если оно будет?
Здравствуйте, Аноним, Вы писали:
А>Слепой с глухим.
Это, типа, наезд?
А>Будет ли промежуточное представление или будет будет необходимость описывать все возможные трансформации?
Да, будет. И скорее всего не одно. Но его можно будет использовать, а можно не использовать. Мы не принуждаем к этому.
А>Каким будет промежуточное представление если оно будет?
Скажем для дотнета будет нечто вроде типизированного АСТ немерла. В нем минимум констуркций, никакой расширяемости и все однозначно.
При трансляции можно будет разбирать исходное АСТ (содержащее информацию о типах) с помощью паттерн-матчинга и квази-цитат (их поддержка будет генерироваться по декларативному описанию).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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 разработчиков. Которые, в массе своей, не любят, чтобы их загоняли в светлое будущее палками.
Re[11]: [draft] N2 – языковый фрeймворк
От:
Аноним
Дата:
23.03.12 04:14
Оценка:
Здравствуйте, VladD2, Вы писали:
А>>Каким будет промежуточное представление если оно будет?
VD>Скажем для дотнета будет нечто вроде типизированного АСТ немерла. В нем минимум констуркций, никакой расширяемости и все однозначно.
VD>При трансляции можно будет разбирать исходное АСТ (содержащее информацию о типах) с помощью паттерн-матчинга и квази-цитат (их поддержка будет генерироваться по декларативному описанию).
Вообщем тумана еще больше. Есть фортран. Его надо транслировать в ллвм и надо транслировать в нет. Фронт как я понимаю будет одинаковым. Дальше как будет идти? Причем по обеим ветвям.
Здравствуйте, VladD2, Вы писали:
VD>* О том как из Н2 можно извлечь выгоду (монетизировать).
Я вот не уверен, были ли здесь уже дискуссии на эту тему, но мне очень любопытно. Я с огромным сочувствием отношусь к Nemerle, даже чуток выучил. К тому же я — эсперантист, это по-своему "Nemerle среди натуральных языков"
У меня есть кой-какая власть в выборе технологий, и в принципе работаю в довольно DSL'ных областях, казалось бы вот оно. Но, по-моему, главная проблема в монетизации — как-то уж больно мала роль собственно программирования в задаче разработки программного продукта. Т.е. основные сложности лежат в области коммуникации, осознании требований, учёте деталей, выработки "языка проекта", придумывании/выборе алгоритмов. Эти же факторы поддерживают "неэффективные" языки.
Здравствуйте, Nuseraro, Вы писали:
N>У меня есть кой-какая власть в выборе технологий, и в принципе работаю в довольно DSL'ных областях, казалось бы вот оно. Но, по-моему, главная проблема в монетизации — как-то уж больно мала роль собственно программирования в задаче разработки программного продукта. Т.е. основные сложности лежат в области коммуникации, осознании требований, учёте деталей, выработки "языка проекта", придумывании/выборе алгоритмов. Эти же факторы поддерживают "неэффективные" языки.
Одно из главных преимущество ДСЛ-ного подхода заключается в том, что он позволяет пробовать алгоритмы решения задачи не меняя реализации.
ДСЛ декларативен. Он описывает задачу, а не ее решение. А решение может быть сгенерированно такое какое нужно.
При работе над тем же генератором парсеров Вольфхаунд уже несколько раз изменил внутреннею реализацию, а ДСЛ изменился не так значительно (поправить грамматику можно за 10 минут).
На задачах где решение не очевидно с самого начала — это дает определенную свободу.
Кроме того сама выработка ДСЛ-я приводит к осмысливанию предметной области.
Все это уже оказывает влияние на сам процесс проектирования, и как следствие на результат. Уже не так страшно ошибиться в дизайне приложения. Ведь все можно довольно просто справить.
К тому же задачи бывают разные. В некоторых объем кодирования настолько велик, а цена ошибки высока, что использование метапрограммирвоания является безусловным преимуществом.
Просто надо освоить этот подход и применить его пару раз на практике.
Лично у меня все сомнения исчезли после первого применения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Вообщем тумана еще больше. Есть фортран. Его надо транслировать в ллвм и надо транслировать в нет. Фронт как я понимаю будет одинаковым. Дальше как будет идти? Причем по обеим ветвям.
Это зависит от ряда деталей.
Могут быть следующие варианты:
1. (пессимистический) Нет ни бэкэндов, ни кода трансляции в них. Тогда придется писать оба бэкэнда и код трансляции в них. При этом можно постараться использовать промежуточный язык имеющийся для других бэкэндов, да и код других бэкндов (хотя в последнем случае процент повторного использования будет не велик).
2. Имеются подходящие бэкэнды, но нет трансляции в них и нет общего низкоуровнего языка. Тогда нужно написать
две трансляции в каждый из бэкэндов, или создавать промежуточный язык и транслировать с него + делать одну трансляцию промежуточного языка бэкнд.
3. (оптимистический) Имеется низкоуровневый промежуточный язык для которого уже написана трансляция в оба бэкнда. Тогда надо всего лишь написать трансляцию из АСТ (точнее это дерево разбора) в этот промежуточный зык.
Да, забыл упомянуть. Кроме трасляции в бэкэнд еще нужно чтобы язык был совместим с метаданными предоставляемыми бэкэдом или написать конвертер метаданных. Метаданные описывают типы, методы, атрибуты и другую фигню которая есть в языке. Скажем у Хаскеля не будет наследования и классов, но будут классы типов, модули и т.п. Если бэкнд не поддерживает классов типов, то их придется эмулировать на основе имеющихся примитивов (или бэкэнд не подойдет).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: [draft] N2 – языковый фрeймворк
От:
Аноним
Дата:
23.03.12 13:05
Оценка:
Здравствуйте, 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>Которые, в массе своей, не любят, чтобы их загоняли в светлое будущее палками.
Тебя никто не загоняет. Каменный молоток остался в целости и сохранности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Стало яснее. Спасибо. Добавь плз это и блок-схему(подсистемы и кто кого посылает от кого зависит) в драфт. Станет намного лучше и понятнее. Еще раз спасибо.
ОК. Что-нибудь придумаем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Разбирать С++ без семантического анализа невозможно. А для семантического анализа придётся поддерживать кучу фич полноценного компилятора.
Все что нужно для разбора С++ — это таблица символов, чтобы отделять типы от идетификаторов.
Это у нас будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Попробовал. Компиляция прошла успешно. Еще вопросы?
Компиляция чего? Проекта? По умолчанию компиляция вьюхи происходит в момент ее первого использования.
VD>Ты видимо полагаешь, что раз IDE подсвечивает теги, то их и компилятор не пропустит. Вот только это не так.
VD>Разор — это тупой текстуальный препроцессор. Я тебе уже раз сто сказал, что интеллекта в нем — 0 целых хрен десятых, но ты споришь.
Это обычный язык. Как и многие другие языки, он парсит исходники, строит AST и компилирует его. Для этого не надо обладать интеллектом.
Я не агитирую за него, просто мне не нравится, когда ты выдаешь неверные, но безапелляционные утверждения о тех технологиях, о которых знаешь понаслышке. Пример "компиляции" и твоего объяснения, почему она прошла очень показателен.
Здравствуйте, Ziaw, Вы писали:
VD>>Ты видимо полагаешь, что раз IDE подсвечивает теги, то их и компилятор не пропустит. Вот только это не так.
ОК, тут я не прав. Меня смутило то, что вот такой вот код:
<h2>@ViewBag.Message</h2
компилируется и отображает результат, не смотря на явную проблему.
Z>Я не агитирую за него, просто мне не нравится, когда ты выдаешь неверные, но безапелляционные утверждения о тех технологиях, о которых знаешь понаслышке. Пример "компиляции" и твоего объяснения, почему она прошла очень показателен.
А тебе нравится, что твои претензии не по делу? Даже если разоровский парсер проверят структуру ХТМЛ-я, то мы без проблем это воспроизведем.
Когда же я тебе говорил о построении дерева в рантайме, то речь шла далеко не только о проверке самого ХМТЛ-я. Речшь шла о безопасности помещаемых в него данных и о возможностях по пост-обработке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Разбирать С++ без семантического анализа невозможно. А для семантического анализа придётся поддерживать кучу фич полноценного компилятора. VD>Все что нужно для разбора С++ — это таблица символов, чтобы отделять типы от идетификаторов.
Хахахаххахаахахах.
VD>Это у нас будет.
1) С++ требует двух стадий разбора для шаблонов. Т.е. простой таблицей символов не обойтись.
2) Если забить на пункт 1 (как это сдалал MS), то в коде шаблонов нужно вычислять тип параметров для того, чтобы определить тип это или идентификатор. Для вычисления параметра шаблона нужно реализовать практически весь С++.
Здравствуйте, Cyberax, Вы писали:
C>1) С++ требует двух стадий разбора для шаблонов. Т.е. простой таблицей символов не обойтись.
Не пори чушь. Для парсинга достаточно таблицы симвлово.
C>2) Если забить на пункт 1 (как это сдалал MS), то в коде шаблонов нужно вычислять тип параметров
Чего, чего? Может тип параметра типа?
C>для того, чтобы определить тип это или идентификатор. Для вычисления параметра шаблона нужно реализовать практически весь С++.
Шаблоны нужно разбирать в промежуточное представление. Все равно до воплощения их стипизировать невозможно. Концепты врде как не прошли в стандарт.
C>Ты просто не представляешь сложности задачи.
Возможно. Не ясно только как создали пасрер С++ для АНТЛР. Наверно они тоже недопонимали сложности задачи .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [draft] N2 – языковый фрeймворк
От:
Аноним
Дата:
25.03.12 12:06
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Шаблоны нужно разбирать в промежуточное представление. Все равно до воплощения их стипизировать невозможно. Концепты врде как не прошли в стандарт.
Конценты достаточно вероятно войдут в 2013 промежуточный стандарт. Кроме них и пары мелочей больше изменений скорей всего не будет.
Следующая версия не промежуточная будет не скоро.
Здравствуйте, Аноним, Вы писали:
А>Конценты достаточно вероятно войдут в 2013 промежуточный стандарт. Кроме них и пары мелочей больше изменений скорей всего не будет.
Достаточно вероятно, что 2013-ый стандарт превртится в 2023-ий .
А так концепты конечно могут помочь типизировать шаблоны до раскрытия, но ведь они не обазательны будут. А значит все равно придется реализовывать старый подзод. Плюс концепты могут не покрывать все описания и часть кода шаблонов останется нетипизированной.
Так что по фиг.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>1) С++ требует двух стадий разбора для шаблонов. Т.е. простой таблицей символов не обойтись. VD>Не пори чушь. Для парсинга достаточно таблицы симвлово.
Недостаточно.
C>>2) Если забить на пункт 1 (как это сдалал MS), то в коде шаблонов нужно вычислять тип параметров VD>Чего, чего? Может тип параметра типа?
Нужно вычислять какая подстановка сработает, и какой будет зависимый тип.
C>>для того, чтобы определить тип это или идентификатор. Для вычисления параметра шаблона нужно реализовать практически весь С++. VD>Шаблоны нужно разбирать в промежуточное представление. Все равно до воплощения их стипизировать невозможно. Концепты врде как не прошли в стандарт.
До воплощения шаблоны не просто можно, а нужно проверять (это первый шаг двухфазного поиска).
C>>Ты просто не представляешь сложности задачи. VD>Возможно. Не ясно только как создали пасрер С++ для АНТЛР. Наверно они тоже недопонимали сложности задачи .
А они и не создали. Не существует полного парсера С++ на автономном генераторе парсеров, везде используется парсер, совмещённый с семантическими действиями, использующими полноценный комилятор.
Парсеры для подмножества С++ существуют. Я когда-то лично откручивал от gcc тамошний yacc-based парсер С++ (его выкинули в районе 2004-го года) и отпиливал от него весь лишний интеллект для разбора простых заголовков.
Здравствуйте, nikov, Вы писали:
N>Невозможно стипизировать полностью. Тем не менее, желательно, чтобы интеллисенс по возможности работал и внутри шаблонов.
Для того что можно вычислить в шаблоне, интелисенс сделать можно. Но это крохи.
Реально для полноценного интелисенса нужно или типизировать его в контексте одного из применений (а то и нескольких), или вводить концепты.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>>>1) С++ требует двух стадий разбора для шаблонов. Т.е. простой таблицей символов не обойтись. VD>>Не пори чушь. Для парсинга достаточно таблицы симвлово. C>Недостаточно.
Примеры, демонстрирующие недостаточность, в студию.
C>>>2) Если забить на пункт 1 (как это сдалал MS), то в коде шаблонов нужно вычислять тип параметров VD>>Чего, чего? Может тип параметра типа? C>Нужно вычислять какая подстановка сработает, и какой будет зависимый тип.
Ты хоть выражайся так чтобы тебя понять можно было. Что за параметры? Какая на фиг постановка?
VD>>Шаблоны нужно разбирать в промежуточное представление. Все равно до воплощения их стипизировать невозможно. Концепты врде как не прошли в стандарт. C>До воплощения шаблоны не просто можно, а нужно проверять (это первый шаг двухфазного поиска).
Нихрена там не проверишь до воплощения. Только распарсить можно. И то с костылями вроде typename и template, так как без этого неоднозначность на неоднозначности.
C>>>Ты просто не представляешь сложности задачи. VD>>Возможно. Не ясно только как создали пасрер С++ для АНТЛР. Наверно они тоже недопонимали сложности задачи . C>А они и не создали. Не существует полного парсера С++ на автономном генераторе парсеров, везде используется парсер, совмещённый с семантическими действиями, использующими полноценный комилятор.
Для особо упертых. Таблица символов — это и есть "семантические действия". Все что нужно для парсинга С++ в соответствии со стандартом — это знать чем является идентификатор — типом, или нет. Вот это знание и дает таблица символов. Когда находится очередное описание типа (класс, тайпдеф, ...) информация об имени заносится в таблицу символов текущей области видимости. В дальнейшем эта информация используется для определения того является ли имя именем типов.
C>Парсеры для подмножества С++ существуют. Я когда-то лично откручивал от gcc тамошний yacc-based парсер С++ (его выкинули в районе 2004-го года) и отпиливал от него весь лишний интеллект для разбора простых заголовков.
Его выкинули, потому что автоматные топ-даун-парсеры практически не пригодны для разбора контекстно зависмых языков.
Смотреть на него не нужно было исходно. А вот парсер из АНТЛР парсит С++ весьма не плохо (по словам тех кто его пользовал). Даже сделали порт АНТЛР на С++, чтобы можно было этот парсер использовать.
На же парсер долежен взять С++ без малеший проблем. В нем есть все для его разбора. И парсинг с откатами, и поддержка таблицы символов (будет).
Так что теоретических проблем с парсингом С++ нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
