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

H>С++ не знаю. Razor (под C#) сделать уже сейчас на Nemerle.Peg не проблема.

Проблема в том, что это будет только парсер.

На Н2 можно будет залудить полную поддержку. Да и сам движок Разора за одно реализовать.

Здравствуйте, 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'а

Автор: WolfHound
Дата: 29.12.11

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

Так и не понял как разрешаются. Первое предположение — приоритеты. Приоритеты — это магические цифры и их лучше собирать в одном месте и хорошо комментировать. Как-то это плохо соотносится с подключаемыми самописными модулями.

_>>Точки расширения с ограничениями грамматики? Как правильно их описать?
WH>Чего?
Например можно сделать основной скелет языка, в который можно встраивать "выражения", и точка расширения для своих "выражений" может быть описан ограниченным шаблоном грамматики, в котором не могут быть конструкции из основного скелета. Как эти шаблоны описывать?

_>>Как будет "джунгли из многоствольных деревьев" проецироваться в однозначное "дерево"?
WH>А зачем джунгли? Джунгли это комбинаторный взрыв и куча неоднозначностей на ровном месте. Смотри мое сообщение про правило разрешения конфликтов.
WH>И что характерно любой разобранный вариант можно типизировать.

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

_>>Более практичный вопрос на закуску: как будут передаваться значения из модуля с своей грамматикой и структурой данных в другой модуль с другой структурой данных? Например: как передать "красное-черное дерево" из питон-модуля в лисп-модуль?
WH>Языки должны быть совместимы на уровне бекенда.
Предположим оба языка и лисп и питон компилируются под один бекенд, например язык СИ. Как мне передать из питона в лисп последовательность-тупл, так чтобы на лиспе можно было бы обойти все элементы map'ом? Это кстати важный момент при работе со со всякими дсл'ями — взаимодействие основной программы с этим дсл.

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

_>То есть нет ни ВМ, ни базой структуры АСТ, ни парсера. Мне лень писать на этом фреймворке что-нибудь практичное, так как все придется делать самому: ВМ, под него АСТ, под АСТ писать парсер.
Не правильно.
Будет несколько языков и бекендов в стандартной поставке.

WH>>https://github.com/rampelstinskin/ParserGenerator
_>Содержательно, а главное всем понятно.
Это новый алгоритм описание, которого пока не существует в природе.

_>Так и не понял как разрешаются.
Что конкретно не ясно?

_>Первое предположение — приоритеты. Приоритеты — это магические цифры и их лучше собирать в одном месте и хорошо комментировать. Как-то это плохо соотносится с подключаемыми самописными модулями.
Это не приоритеты, а сила связывания. И цифры там временно.

_>Например можно сделать основной скелет языка, в который можно встраивать "выражения", и точка расширения для своих "выражений" может быть описан ограниченным шаблоном грамматики, в котором не могут быть конструкции из основного скелета. Как эти шаблоны описывать?
Ничего не понял.

_>Никак не ограниченные расширения породят этот лес. И надо придумать инструмент разрешающий эти конфликты: алгоритмы слияния, разрешения неоднозначности интерактивными инструментами и тп.
Не породят. Парсер однозначный. Если конечно кто-то специально не создать два идентичных правила.

_>Предположим оба языка и лисп и питон компилируются под один бекенд, например язык СИ. Как мне передать из питона в лисп последовательность-тупл, так чтобы на лиспе можно было бы обойти все элементы map'ом? Это кстати важный момент при работе со со всякими дсл'ями — взаимодействие основной программы с этим дсл.
Это решаемая проблема. Конкретики у меня пока нет.
А в случае с питоном и лиспом и решать то нечего. Оба динамически типизированные.

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

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

_>>То есть нет ни ВМ, ни базой структуры АСТ, ни парсера. Мне лень писать на этом фреймворке что-нибудь практичное, так как все придется делать самому: ВМ, под него АСТ, под АСТ писать парсер.
WH>Не правильно.
WH>Будет несколько языков и бекендов в стандартной поставке.
Как связан язык и бак? Если есть 5 языков и 3 бака то надо делать 15 генераторов?

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

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

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

Комплируемость и динамическая типизация вещи ортогональные. C# с dynamic тоже динамически типизируем

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

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

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

H>Комплируемость и динамическая типизация вещи ортогональные. C# с dynamic тоже динамически типизируем

вообще то я о лиспе с статической типизацией. Есть и такое.

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

_>>Первое предположение — приоритеты. Приоритеты — это магические цифры и их лучше собирать в одном месте и хорошо комментировать. Как-то это плохо соотносится с подключаемыми самописными модулями.
WH>Это не приоритеты, а сила связывания. И цифры там временно.

Сила связывания — что это такое? Что будет вместо магических чисел.

_>>Никак не ограниченные расширения породят этот лес. И надо придумать инструмент разрешающий эти конфликты: алгоритмы слияния, разрешения неоднозначности интерактивными инструментами и тп.
WH>Не породят. Парсер однозначный. Если конечно кто-то специально не создать два идентичных правила.
Парсер то может быть и однозначный (доказательства?), но контекстно свободные грамматики в общем случае неоднозначны, и любят порождать "лес многоствольных деревьев", при этом этот лес может быть однозначным по смыслу. И любая помощь в разрешении этого — это очень хорошо для разработчика.

Пример
Expr = Expr + Expr
Expr = Expr — Expr
Expr = 'a'

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

_>>Предположим оба языка и лисп и питон компилируются под один бекенд, например язык СИ. Как мне передать из питона в лисп последовательность-тупл, так чтобы на лиспе можно было бы обойти все элементы 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 описанная в этом алгоритме.

Плюс несколько своих доработок напильником.

_>Что будет вместо магических чисел.
Каждая сила связывания получит свое имя.
И порядок относительно других сил связывания.

_>Парсер то может быть и однозначный (доказательства?),
Он так построен.

_>но контекстно свободные грамматики в общем случае неоднозначны,
Я в курсе. Но у меня парсер разбирает не КС грамматики.
Так что мимо.
Более того я считаю все попытки построить парсер по КС грамматике глупостью.
Ибо КС грамматика описывает не разбор, а генерацию текста.
А я работаю именно с разбирающей, а не генерирующей грамматикой.
Поэтому у меня и нет неоднозначностей.

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

_>Эти правила написаны в разных модулях расширяющих грамматику, поэтому сложно синхронизировать эти магические числа-приоритеты.
Так их в конечной версии и не будет.

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

Здравствуйте, 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>т.к. если хочется парсить с++, то надо брать clang и делать из него выхлоп

Спорим на три штуки баксов, что когда парсер Н2 начнет поддерживать таблицу имен, я смастерю парсер С++ за меся.

Была бы качественная грамматика.

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

ME>и вообще, я не вижу особого смысла делать DSL-довески над *синтаксисом* c++
ME>вот, скажем, сконвертить с++ в какой-то приличный синтаксис и там поднавесить DSL-довески — это реально

Мы не собираемся делать С++-парсеры. Но сделать это будет возможно и относительно не сложно. В прочем, может быть сделаем парсер С++ просто в качестве теста и чтобы подразнить всех тех кто считает, что это невозможно.

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

А>Каким будут подсистемы, как они взаимосвязаны(рисунок).

Что понимается под "подсистемами"?

А>Примеры куском для каждой подсистемы. Если с парсером более менее понятно, то с остальными.

В ближайшее время покажу парсер, области видимости и вычисляемые атрибуты.

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

Перечислять невозможное можно бесконечно.

А>Оптимизации кода, где они будут сосредоточены/распределены?

В бэкэндах.

А>Будет ли возможность реализовать С++, Перл, Руби (или их подмножество)и почему нет.

Будет.

А>Насколько упроститься/усложниться при этом работа.

Все что связано с разбором и типизацией (проверки корректности, выявления типов, разрешением неоднозначностей) будет выполняться автоматически на основании декларативных описаний. Соответственно работа в этой части будет упрощена до предела. Фактически будет требоваться создать формальную спецификацию, а весь код будет сгенерирован автоматом.

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

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

_C_>Непонятно, почему за бортом остались динамические и полудинамические языки. игнорите?

В смысле, за бортом? Для них есть DLR, на которой можно строить динамику уже сейчас, в N1. Просто тут это особо нужно никому не было

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

_>То есть нет ни ВМ, ни базой структуры АСТ, ни парсера.

Ага. И это супер круто!

_>Мне лень писать на этом фреймворке что-нибудь практичное, так как все придется делать самому: ВМ, под него АСТ, под АСТ писать парсер.

Неверный вывод. То что нет "базой структуры АСТ, ни парсера" не означает, что их нужно писать вручную.
Вместо них есть ДСЛ-и для их описания. И возможность использования готовых решений (импорт и расширение модулей).

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

_>Так и не понял как разрешаются. Первое предположение — приоритеты. Приоритеты — это магические цифры и их лучше собирать в одном месте и хорошо комментировать. Как-то это плохо соотносится с подключаемыми самописными модулями.

Гугли на тему Top Down Operator Precedence (TDOP, он же Pratt-парсер). Описаний мало, но они есть.

_>Например можно сделать основной скелет языка, в который можно встраивать "выражения", и точка расширения для своих "выражений" может быть описан ограниченным шаблоном грамматики, в котором не могут быть конструкции из основного скелета. Как эти шаблоны описывать?

Можно. Объявляешь любой правило расширяемым и расширяй его сколько угодно. Например, если есть правило Expression и тебе надо сделать правило MyExpression расширяющее его ты можешь написать нечто такое:

MyExpression is Expression = "my-prefix" MyRule;
MyRule : MyAst; // свое расширяемое правило

_>Никак не ограниченные расширения породят этот лес. И надо придумать инструмент разрешающий эти конфликты: алгоритмы слияния, разрешения неоднозначности интерактивными инструментами и тп.

Это какая-то научная фантастика основанная на голом теоретизировании.
На практике люди не пишут бездумных расширений.

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

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

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

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

А>вообще то я о лиспе с статической типизацией. Есть и такое.

Вообще-то в стандарт CL типизация вроде как не входит. Или я что-то путаю?

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

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

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

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