Хочу создать свой ЯП дабы понять всю трудность и проблемы оного.
При этом я не хочу заморачиватся на парсерах, синтаксисе.
Поэтому
1. в качестве базового языка выбираю XML.
2. делаю XSD схему чтобы не совсем строго но как то ограничить входное множество сорцов. да и для интелисенса полезно, редактор же я не собираюсь писать.
3. делаю объектную модель дерева выражений, и парсер. с XML это должно быть очень просто.
Это начало, не сделал ли я здесь лишних шагов? может все еще проще можно сделать?
Далее мне надо мое дерево выражений транслировать в какой то более распр. язык. Ну не генерить же мне в самом деле код вручную.
Например буду генерить C#.
А цель всего оного — проверить придуманое дерево выражений на предмет удобства, возможностей в области обобщенного программирования.
Высказывайтесь, может кто уже прошел этот путь и есть экспиринс?
Здравствуйте, barn_czn, Вы писали:
_>Это начало, не сделал ли я здесь лишних шагов? может все еще проще можно сделать?
Лишних шагов вы сделали ровно 3 (три):
_>1. в качестве базового языка выбираю XML. _>2. делаю XSD схему чтобы не совсем строго но как то ограничить входное множество сорцов. да и для интелисенса полезно, редактор же я не собираюсь писать. _>3. делаю объектную модель дерева выражений, и парсер. с XML это должно быть очень просто.
Первым шагом нужно было рассказать в какой области язык будет использоваться, какие задачи на нем будут решаться, как будет выглядеть какая-нибудь простая типовая программа, кто в конце концов будет им пользоваться.
Здравствуйте, barn_czn, Вы писали:
_>Как говорится хочу странного. _>1. в качестве базового языка выбираю XML. _>2. делаю XSD схему чтобы не совсем строго но как то ограничить входное множество сорцов. да и для интелисенса полезно, редактор же я не собираюсь писать. _>3. делаю объектную модель дерева выражений, и парсер. с XML это должно быть очень просто. _>Это начало, не сделал ли я здесь лишних шагов? может все еще проще можно сделать?
Можно проще — написать нормальный парсер. Собственно, даже не "написать", а использовать какой-нибудь распространенный генератор парсеров. Если знакомы с Немерле, то сейчас хорошей альтренативой видится Nemerle.PEG. Если нет, то могу порекомендовать CoCo/R. Не думаю, что использование ХМЛ упростит вам задачу. Если вы понимаете, чего хотите, то написание EBNF-грамматики займет примерно столько же времени, сколько и описание XML схемы.
А язык, основанный на ХМЛ, это какая-то мертворожденная идея.
_>Далее мне надо мое дерево выражений транслировать в какой то более распр. язык. Ну не генерить же мне в самом деле код вручную. _>Например буду генерить C#.
Если вы считаете, что это сильно проще, чем, скажем, генерировать MSIL, то мне кажется вы заблуждаетесь. По сути вы хотите один высокоуровневый язык транслировать в другой. Это не так уж и просто. Если, конечно, ваш язык не является клоном C#.
_>А цель всего оного — проверить придуманое дерево выражений на предмет удобства, возможностей в области обобщенного программирования. _>Высказывайтесь, может кто уже прошел этот путь и есть экспиринс?
А что интересно? На сайте, кстати, есть моя статья, описывая подобный "экспиринс". Правда, я делал собственную VM.
ВВ>Можно проще — написать нормальный парсер. Собственно, даже не "написать", а использовать какой-нибудь распространенный генератор парсеров. Если знакомы с Немерле, то сейчас хорошей альтренативой видится Nemerle.PEG. Если нет, то могу порекомендовать CoCo/R. Не думаю, что использование ХМЛ упростит вам задачу. Если вы понимаете, чего хотите, то написание EBNF-грамматики займет примерно столько же времени, сколько и описание XML схемы.
EBNF действительно попроще составления xsd. Но конечный пользователь этих проблем не чувствует. Это мои проблемы. А вот изначально негативное отношение
к новому синтаксису — это уже просто аксиома. Люди в основной массе не желают изучать новые языки и привыкать к новому синтаксису, это всегда было и будет барьером.
Степанов, например, на счет питона кажется тоже сказал — зачем новый синтаксис, что он внес кроме проблем привыкания ?
ВВ>А язык, основанный на ХМЛ, это какая-то мертворожденная идея.
Правда? А как же XHTML, SVG, XAML. Последний думаю оправдал себя на все 100%, очень удачная идея. И это все языки XML based.
И как показывает практика — проще разобраться со схемой XML чем изучать синтаксис, потом учится кодить на нем.. Хватит уже новых синтаксисов.
_>>Далее мне надо мое дерево выражений транслировать в какой то более распр. язык. Ну не генерить же мне в самом деле код вручную. _>>Например буду генерить C#.
ВВ>Если вы считаете, что это сильно проще, чем, скажем, генерировать MSIL, то мне кажется вы заблуждаетесь. По сути вы хотите один высокоуровневый язык транслировать в другой. Это не так уж и просто. Если, конечно, ваш язык не является клоном C#.
Грубо, но все же можно считать, что множество выражений MSIL есть подмножество выражений C#. Так почему бы мне не использовать C#? И почему это сложнее?
_>>А цель всего оного — проверить придуманое дерево выражений на предмет удобства, возможностей в области обобщенного программирования. _>>Высказывайтесь, может кто уже прошел этот путь и есть экспиринс?
ВВ>А что интересно? На сайте, кстати, есть моя статья, описывая подобный "экспиринс". Правда, я делал собственную VM.
Спасибо. Посмотрю. Но как я уже сказал, разработчики новых языков, приступая к работе сразу делают делают стратегически неверные шаги. Не надо пускаться в придумывание
нового синтаксиса. Если вы делаете императивный ЯП — не надо заменять { на begin.
Если вы делаете функциональный ЯП — так возьмите за основу синтаксис уже популярного в ваших кругах ЯП, и расширьте его если надо.
Ну что толку от нового F#, его даже изучать никто не хочет потому что это и не шарп по синтаксису и не скала.
Барьер нового синтаксиса в ЯП — это большой барьер. Не согласен с теми кто говорит "да что там привыкать, взял прочитал да и пиши". Вот не пишут, не хотят.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, barn_czn, Вы писали:
_>>Это начало, не сделал ли я здесь лишних шагов? может все еще проще можно сделать?
H>Лишних шагов вы сделали ровно 3 (три):
_>>1. в качестве базового языка выбираю XML. _>>2. делаю XSD схему чтобы не совсем строго но как то ограничить входное множество сорцов. да и для интелисенса полезно, редактор же я не собираюсь писать. _>>3. делаю объектную модель дерева выражений, и парсер. с XML это должно быть очень просто.
H>Первым шагом нужно было рассказать в какой области язык будет использоваться, какие задачи на нем будут решаться, как будет выглядеть какая-нибудь простая типовая программа, кто в конце концов будет им пользоваться.
К какой области относится C# ?
Допустим я принимаю за основу дерево выражений C#. А синтаксис XML. Чтото вроде
Такой проект кстати где то ведется. Далее я хочу поэкспериментировать.
Хочу сделать чтобы в генериках можно было наследоваться от типа-параметра:
class A<T> : T
{}
Я осознаю что это будет уже не C# и поэтому намеренно, хотя бы на первом этапе, отказываюсь от синтаксиса C# и перехожу на XML.
Я экспериментирую, но не начальном этапе где выдумывают синтаксис. Важно дерево выражений, его выразительная мощность.
Здравствуйте, barn_czn, Вы писали:
_>Если вы делаете функциональный ЯП — так возьмите за основу синтаксис уже популярного в ваших кругах ЯП, и расширьте его если надо.
И _>Ну что толку от нового F#, его даже изучать никто не хочет потому что это и не шарп по синтаксису и не скала.
_>Допустим я принимаю за основу дерево выражений C#. А синтаксис XML. Чтото вроде
_><namespace name="MyNamespace"> _> <class name="MyClass"> _> </class> _></namespace>
Ух, я вспоминаю былые времена RSDN и рубки про синтаксический оверхед
Здравствуйте, barn_czn, Вы писали:
_>к новому синтаксису — это уже просто аксиома. Люди в основной массе не желают изучать новые языки и привыкать к новому синтаксису, это всегда было и будет барьером.
Ну вы все правильно говорите, человек, которого изучение синтаксиса отпугнет, и язык скорее всего изучать не будет.
_>Степанов, например, на счет питона кажется тоже сказал — зачем новый синтаксис, что он внес кроме проблем привыкания ?
Необязательно придумывать новый синтаксис, можно использовать существующий. Например, Си-подобный. "Зачем нужен новый синтаксис" — это вопрос, который прежде всего стоит задать самому себе. И здесь все очень просто на самом деле. Принципиально новый формальный язык нужен в том случае, если вы хотите с помощью него выражать вещи, которые плохо выражаются на других языках.
ВВ>>А язык, основанный на ХМЛ, это какая-то мертворожденная идея. _>Правда? А как же XHTML, SVG, XAML. Последний думаю оправдал себя на все 100%, очень удачная идея. И это все языки XML based. _>И как показывает практика — проще разобраться со схемой XML чем изучать синтаксис, потом учится кодить на нем.. Хватит уже новых синтаксисов.
Это все не языки, а скорее этакие маркапы. И разобраться с ХМЛ, конечно, несложно, но вот писать на нем — это ад. Чего тут спорить-то, собственно, представьте, как на вашем языке будет выглядеть простейшие арифметические операции, скажем:
2 + 3 * 4
И сравните.
ВВ>>Если вы считаете, что это сильно проще, чем, скажем, генерировать MSIL, то мне кажется вы заблуждаетесь. По сути вы хотите один высокоуровневый язык транслировать в другой. Это не так уж и просто. Если, конечно, ваш язык не является клоном C#. _>Грубо, но все же можно считать, что множество выражений MSIL есть подмножество выражений C#. Так почему бы мне не использовать C#? И почему это сложнее?
Я не знаю, что за язык у вас и насколько однозначно он может транслироваться в C#.
Если язык строится на других парадигмах, то генерация C# задачу компиляции никак не упрощает. Напротив, вам придется соблюдать семантику C#, его особенности — например, представьте, что нужно язык, поддерживающий затенение переменных при объявлении на манер С++, транслировать в C#. Вот вам куча геморроя на ровном месте. В МСИЛе такого не будет. Вообще примеров много тут можно наскрести.
Если вы считаете, что аутпут генератора облегчит отладку, то это тоже маловероятно. Аутпут будет представлять собой лапшу из кода и препроцессора, всяческих #line. Разгребать эту гору будет ничуть не проще, чем анализировать листинги байт-кода.
Единственный плюс — возможность использовать оптимизатор C#. Но мне кажется несколько неправильным начинать разработку с оптимизатора.
По уму вообще надо генерировать абстрактное низкоуровневое АСТ или даже свой набор инструкций, некий Abstract IL, а потом уже писать отдельный транслятор для всего этого добра — в C#, MSIL, JavaScript, C-- и т. д.
_>>>А цель всего оного — проверить придуманое дерево выражений на предмет удобства, возможностей в области обобщенного программирования. _>>>Высказывайтесь, может кто уже прошел этот путь и есть экспиринс?
ВВ>>А что интересно? На сайте, кстати, есть моя статья, описывая подобный "экспиринс". Правда, я делал собственную VM. _>Спасибо. Посмотрю. Но как я уже сказал, разработчики новых языков, приступая к работе сразу делают делают стратегически неверные шаги. Не надо пускаться в придумывание _>нового синтаксиса. Если вы делаете императивный ЯП — не надо заменять { на begin. _>Если вы делаете функциональный ЯП — так возьмите за основу синтаксис уже популярного в ваших кругах ЯП, и расширьте его если надо.
Ну так и сделайте так. Я именно так и поступил.
А XML не является привычным синтаксисом ни для императивного, ни для функционального языка.
_>Ну что толку от нового F#, его даже изучать никто не хочет потому что это и не шарп по синтаксису и не скала.
Вот тут не понял. F# как раз использует "мейнстрим" синтаксис для функциональных языков. ФЯ с Си-подобным синтаксисом вообще не так много. Большинство использует варианты ML-ного синтаксиса. В полном соответствии с вашим утверждением выше. Это не говоря о том, что F# это вариант OCaml и даже поддерживает кросскомпиляцию на определенном уровне.
_>Барьер нового синтаксиса в ЯП — это большой барьер. Не согласен с теми кто говорит "да что там привыкать, взял прочитал да и пиши". Вот не пишут, не хотят.
Ну так используйте Си-подобный синтаксис, кто ж вам мешает-то.
Здравствуйте, barn_czn, Вы писали:
_>Такой проект кстати где то ведется. Далее я хочу поэкспериментировать. _>Хочу сделать чтобы в генериках можно было наследоваться от типа-параметра: _>class A<T> : T _>{}
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, barn_czn, Вы писали:
_>>к новому синтаксису — это уже просто аксиома. Люди в основной массе не желают изучать новые языки и привыкать к новому синтаксису, это всегда было и будет барьером.
ВВ>Ну вы все правильно говорите, человек, которого изучение синтаксиса отпугнет, и язык скорее всего изучать не будет.
_>>Степанов, например, на счет питона кажется тоже сказал — зачем новый синтаксис, что он внес кроме проблем привыкания ?
ВВ>Необязательно придумывать новый синтаксис, можно использовать существующий. Например, Си-подобный. "Зачем нужен новый синтаксис" — это вопрос, который прежде всего стоит задать самому себе. И здесь все очень просто на самом деле. Принципиально новый формальный язык нужен в том случае, если вы хотите с помощью него выражать вещи, которые плохо выражаются на других языках.
согласен
ВВ>>>А язык, основанный на ХМЛ, это какая-то мертворожденная идея. _>>Правда? А как же XHTML, SVG, XAML. Последний думаю оправдал себя на все 100%, очень удачная идея. И это все языки XML based. _>>И как показывает практика — проще разобраться со схемой XML чем изучать синтаксис, потом учится кодить на нем.. Хватит уже новых синтаксисов.
ВВ>Это все не языки, а скорее этакие маркапы. И разобраться с ХМЛ, конечно, несложно, но вот писать на нем — это ад. Чего тут спорить-то, собственно, представьте, как на вашем языке будет выглядеть простейшие арифметические операции, скажем:
Ну как же не языки, есть и свой синтаксис и дерево. Это декларативные языки.
На счет писания на XML: конечно писать в блокноте на хмл — ад. Писать в IDE — рай. Я много пишу на XAML в студии, не представляю даже что еще может быт удобнее.
Для сравнения попишите на С в блокноте — тот же ад, что делать избалованы мы уже IDE.
ВВ>
ВВ>2 + 3 * 4
ВВ>
Ну правы. Но это примитивное выражение, которым учат нас в школе, и поэтому их действительно можно позже разрешить вводить без разметки на теги. Вот тут действительно уместно расширение синтаксиса,
но не в сторону нового синтаксиса а в сторону старого доброго языка алгебраических выражений.
ВВ>Ну так используйте Си-подобный синтаксис, кто ж вам мешает-то.
Никто не мешает, просто начать хочу не с синтаксиса. Хочу проверить АСТ, и только потом под него подобрать синтаксис.
А на первых порах юзать XML. Интерес к XML вызван еще вот чем: как транслировать мои выражения в другой компилируемый язык? В XML на это уже есть ответ — XSLT.
Не могу сказать что в восторге от него , но идею можно заимствовать и написать алгоритм трансляции в том же стиле — match template.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, barn_czn, Вы писали:
_>>Такой проект кстати где то ведется. Далее я хочу поэкспериментировать. _>>Хочу сделать чтобы в генериках можно было наследоваться от типа-параметра: _>>class A<T> : T _>>{}
ВВ>Интересно, как вы собираетесь это транслировать.
В шарп? Ясно дело что такой генерик никак не транслируется в шарп. Зато порожденые этим генериком типы уже можно транслировать.
Какая выгода? — Писать код на новом расширеном шарпе, юзая такие супер генерики.. Да, смахивает как то на макросы, Т4.
Здравствуйте, Рысцов Денис, Вы писали:
РД>Здравствуйте, barn_czn, Вы писали:
_>>Хочу создать свой ЯП дабы понять всю трудность и проблемы оного.
РД>Вот хорошая серия про создание своего языка http://thedeemon.livejournal.com/tag/leo
Бегло просмотрел. Стиль изложения нравится. Спасибо.
Здравствуйте, barn_czn, Вы писали:
_>Ну как же не языки, есть и свой синтаксис и дерево. Это декларативные языки.
Это не языки *программирования*. Язык программирования — это, скажем, XSLT. Вот это да, язык. И я бы не сказал, что он выигрывает от своей ХМЛ-ности. Причем он не чисто ХМЛ. А ХМЛ + XPath.
_>На счет писания на XML: конечно писать в блокноте на хмл — ад. Писать в IDE — рай. Я много пишу на XAML в студии, не представляю даже что еще может быт удобнее.
XAML — не язык программирования опять же. Писали бы на ХМЛ примитивные операции, вызовы функций — вспомните, какой дикий оверхед имеет вызов шаблона в XSLT — думали бы иначе.
_>Для сравнения попишите на С в блокноте — тот же ад, что делать избалованы мы уже IDE.
Я часто пишу в блокноте. Вполне удобно.
ВВ>>
ВВ>>2 + 3 * 4
ВВ>>
_>Ну правы. Но это примитивное выражение, которым учат нас в школе, и поэтому их действительно можно позже разрешить вводить без разметки на теги. Вот тут действительно уместно расширение синтаксиса, _>но не в сторону нового синтаксиса а в сторону старого доброго языка алгебраических выражений.
Что такое "старый добрый язык алгебраических выражений"?
В итоге вы закончите тем, что у вас будет два парсера — ХМЛ и свой дополнительный.
ВВ>>Ну так используйте Си-подобный синтаксис, кто ж вам мешает-то. _>Никто не мешает, просто начать хочу не с синтаксиса. Хочу проверить АСТ, и только потом под него подобрать синтаксис.
Я начал с Си-подобного синтаксиса, потому что не был уверен, какой хочу. Потом перевел на МЛ-ный. Где-то в течение дня.
_>А на первых порах юзать XML. Интерес к XML вызван еще вот чем: как транслировать мои выражения в другой компилируемый язык? В XML на это уже есть ответ — XSLT.
Это ответ на проблему, которую ХМЛ сам же и создает. В случае с генератором вы будете сразу создавать АСТ. Здесь вместо простейших семантических действий вам придется писать транслятор XML AST — свой AST. Можно, конечно, отказаться от своего АСТ, но это вообще какой-то неправильный путь. Компилятору придется работать с универсальным АСТ, вместо специализированного. Сомневаюсь, что взлетит.
Кстати, XPath для навигации по графу и так можно использовать, можно запустить XSLT преобразование для графа объектов, без всякого ХМЛ. Только я опять же не уверен, что это правильный путь. Компилятор удобнее всего будет писать на каком-нибудь F#, синтаксис которого вам так не нравится.
Здравствуйте, barn_czn, Вы писали:
_>>>Такой проект кстати где то ведется. Далее я хочу поэкспериментировать. _>>>Хочу сделать чтобы в генериках можно было наследоваться от типа-параметра: _>>>class A<T> : T _>>>{}
ВВ>>Интересно, как вы собираетесь это транслировать. _>В шарп? Ясно дело что такой генерик никак не транслируется в шарп. Зато порожденые этим генериком типы уже можно транслировать.
Тогда это уже не генерик, а шаблон на манер С++. *Совершенно* другая штука.
Здравствуйте, barn_czn, Вы писали:
_>На счет писания на XML: конечно писать в блокноте на хмл — ад. Писать в IDE — рай. Я много пишу на XAML в студии, не представляю даже что еще может быт удобнее.
Это жесть а не язык — сплошной синтаксический оверхед.
Здравствуйте, barn_czn, Вы писали:
_>Хочу создать свой ЯП дабы понять всю трудность и проблемы оного. _>При этом я не хочу заморачиватся на парсерах, синтаксисе. _>А цель всего оного — проверить придуманое дерево выражений на предмет удобства, возможностей в области обобщенного программирования.
Думаю, использование XML ни к чему хорошему не приведет. Сила любого языка в его синтаксисе и семантике.
На языке надо разрабатывать, а конструкции языка потеряются внутри XML.
Если же на первом этапе просто хочется опробовать некоторые идеи, то может стоит остановиться на внутреннем DSL.
Т.е. описывать AST с помощью конструкций C# — и XML разбирать не надо, и среда разработки есть.
На начальном этапе будет не хуже, чем XML. Затем прикрутишь синтаксис.
А лучше всего, изучи Haskell:
Потому что:
1. На нем легко построить парсер твоего языка (на основе Parsec).
2. Знание Haskell + знание C# дадут 95% фич, которые используются в современных языках. Возможно это позволит сделать язык еще лучше.
3. Развитая система типов Haskell и функциональная парадигма позволит удобно работать с AST, выполнять оптимизацию и трансляцию на целевой язык.
4. Haskell это круто
Вот.
_>Высказывайтесь, может кто уже прошел этот путь и есть экспиринс?
Прежде чем "ваять" свой язык программирования, изучите хотя бы наиболее известные существующие.
Особенно рекомендую хаскель и вообще функциональное программирование, лисп и пролог. Ну и немерле.
Если вы их еще не знаете, очень вероятно, что вам здорово "снесет крышу", и вы, возможно, сильно пересмотрите свои взгляды на программирование в целом. Книгу создателя хаскеля "The implementation of functional programming languages" еще можно почитать.
Но, вы, на самом деле, очень умно и непредвзято подходите к этому вопросу.
Людям свойственно мыслить стереотипами, приписывая обязательность исторически сложившимся подходам, традициям и ритуалам. И в программировании это не исключение.
Например, на RSDN в соседней флеймовой ветке есть утверждение о том, что "PEG, в отличие от регулярных выражений, допускает декомпозицию и синтаксис у него лучше читается". Удивительное утверждение! Можно подумать, синтаксис у PEG и регулярных выражений не может быть другим, видимо, он прописан в каких-то международных законах, и в регулярные выражения нельзя ввести декомпозицию.
Кстати, парни в Nemerle тоже, на самом деле, применили нестандартный подход, разрабатывая парсеры языков программирования полностью на PEG, хотя историческими стереотипами всегда было принято отделять лексер и парсер. При упоминании "парсинга языка программирования", многие студенты сразу вспоминают унылую связочку Lex+Yacc.
Поэтому, когда говорят "язык программирования", автоматически подразумевают традиционный суповой набор из синтаксиса, парсинга, кодогенерации и т.п., чтобы сделать очередной компилятор-черный ящик-мясорубку, в которую с одного конца закладывают текст, а она с другого выдает машинный (или виртуально-машинный) код.
Наконец-то, в 2010 году в мэйнстримных языках начали задумываться об архитектуре Compiler-as-Service. Виват! Через столько лет от начала программирования, наконец, доперло, что можно-таки вытащить объектную модель кода из черного ящика и позволить программисту ее использовать. Чем, кроме фантастической инерции и стереотипного мышления можно объяснить столь запоздалый подход к столь очевидному решению?
А что если исследователя языков программирования не интересует синтаксис, и он не хочет возиться с такой нудной вещью как парсинг? И почему он должен однозначно выбрать те или иные синтаксические конструкции, руководствуясь какими-то неведомыми эмоциональными предпосылками?
Почему в C указатель обозначается астериском? Почему в хаскеле композиция обозначается точкой? Почему в C операторные скобки фигурные? А, может, кому-то не нравятся фигурные скобки?
Кто сказал, что парсинг вообще обязателен? Потому что все всегда так делали?
Как видите, и ваше сообщение вызвало ироническую реакцию у тех, кто, видимо, знает, "как заведено", и уверен, что заведено так неспроста, и что по-другому вряд ли получится, так как пробовали уже сто раз по-другому и обламывались. И они правы на 99,999%! (потому что, я, конечно, допускаю, что у кого-то может получиться что-то принципиально новое, но, согласно элементарной статистике, вероятность этого крайне мала).
Это было лирическое отступление.
У меня есть опыт разработки как раз основанного на XML языка программирования типа XAML для описания интерфейсов пользователя.
Что я вам скажу — когда делаешь объектно-ориентированный язык программирования на XML, у тебя все равно есть язык, со своим синтаксисом и семантикой, а сам XML составляет лишь маленькую часть этого синтаксиса. XML дает теги и атрибуты, но все что внутри них вам придется парсить так же, как в любом другом языке. А теги и атрибуты составляют малую часть синтаксиса, без которой спокойно можно было бы обойтись.
XML вам ничего не даст для представления семантики языка, а это самое главное, а не синтаксис. Например, организацию областей видимости имен и разрешение идентификаторов вам все равно придется делать самостоятельно. И еще есть проблема — XML очень мало дает для адекватного представления объектно-ориентированного кода, фактически весь код самого языка программирования будет внутри тэгов и атрибутов, и не будет специфицирован XML'ем, то есть это будет "неструктурированный" с точки зрения XML код, либо это будут трехэтажные XML-конструкции, которые будет тяжело редактировать. Во всяком случае, удобный код с интеллисенсом с помощью XSD вы не сделаете.
Короче говоря — XML, в основном, предоставляет "скобочки и кавычечки", удобство которых вообще сомнительно для универсального программирования. И XSD мало что дает для описания семантики объектно-ориентированного кода.
Либо вам придется сделать "язык внутри XML", либо это будет чистое синтаксическое дерево, редактировать которое будет крайне неудобно.
Насчет универсального языка программирования на XML в принципе — такие разработки давно уже есть, и их даже много. Правда, они не описывают чистое дерево выражений на XML, так как это было бы слишком неудобно.
С деревом выражений в XML есть проблема: формальное, дистиллированное дерево выражений, лишенное каких-либо особенностей синтаксиса, будет представляться в XML крайне объемными и неудобными для ручного редактирования и понимания конструкциями. Простейшие выражения превратятся в огромные куски кода.
На самом деле, парсинг не такая уж сложная тема, особенно если использовать "правильные" технологии вроде PEG. Писать корявые трехэтажные конструкции в XML, я думаю, вам должно быстро надоесть.
И еще есть Nemerle с его возможностями метапрограммирования, где, хотя бы для начала, экспериментировать будет проще. Ну и DSL, как вам посоветовали. Можно с этого хотя бы начать, чтобы понимать, с чем имеешь дело.
Еще интересно будет поковырять проекты Microsoft.Cci.Metadata и Microsoft.Cci.Ast, чтобы представлять, как эти самые деревья реально выглядят.
Я сам сейчас изучаю языки программирования и в учебных целях разрабатываю язык программирования, но с уклоном в сторону естественных языков и искусственного интеллекта.
Здравствуйте, barn_czn, Вы писали:
_>Ну как же не языки, есть и свой синтаксис и дерево. Это декларативные языки. _>На счет писания на XML: конечно писать в блокноте на хмл — ад. Писать в IDE — рай. Я много пишу на XAML в студии, не представляю даже что еще может быт удобнее.
_>Ну правы. Но это примитивное выражение, которым учат нас в школе, и поэтому их действительно можно позже разрешить вводить без разметки на теги. Вот тут действительно уместно расширение синтаксиса, _>но не в сторону нового синтаксиса а в сторону старого доброго языка алгебраических выражений.
Полноценная поддержка подобных "примитивных выражений" равномощна полноценному фронтенду ЯП (если вы, конечно, не имеете в виду только константные выражения, в чем я не вижу смысла), потому как многие языки из одних выражений и состоят.
_>А на первых порах юзать XML. Интерес к XML вызван еще вот чем: как транслировать мои выражения в другой компилируемый язык? В XML на это уже есть ответ — XSLT.
Думаю, что ни хрена не выйдет, если преобразование не тривиальное. Семантику программы вы где на XSLT получите? Хотя, конечно, в принципе, XSLT+XPath — тьюринг-полный язык, и на нем можно сделать весь фронтенд компилятора, но гораздо проще будет это написать на C#, манипулируя AST.
Спасибо. хороший ответ. Я уже третий раз пишу вам ответ и мне третий раз сайт не дает запостить, что за маразм.
И при этом в буфере не запоминает написаное.. капец.
