Уместны ли внутренние "языки" ?
От: PSV100  
Дата: 15.02.12 16:41
Оценка:
Здравствуйте, уважаемые немерлисты. У меня маленький философский вопросик по поводу дизайна всяких своих DSL и ему подобных. Я Немерле только смотрел поверхностно, естественно много чего не знаю, не понимаю, не дочувствываю. Есть мысли попробовать Н на практике, если позволят условия (притягивание net-а в проект может создать проблемы). Я понимаю, что немерлевское расширение синтаксиса — это киллер-идея в дизайне языка. Здесь есть плюсы и минусы, по этому поводу дофига набито фингалов и до сих пор частенько бьют друг другу морду, не об этом речь. Хотя, конечно, из-за этого сложностей хватает, например, MetaLua — на порядок проще, легче (речь именно о восприятии, Lua c MetaLua и Немерле естно функционально несоизмеримы). Но не создает ли такое неограниченное (относительно) расширение перегибов палки для решения своих прикладных задач?
Не все лиспы идут на расширение синтаксиса, например, как кложура, опыт предков у нее есть. В Groovy, напр., есть концепция билдеров, Command chains, GPath и пр. — всё в рамках базового синтаксиса языка, всё гармонично смотрится. Конечно, "конкуренты" Немерля более ограничены в полётах, частенько всё расчитано на динамику и рантайм, а статичный контроль во время компиляции и поддержка всего синтаксиса в IDE плюс все профиты от компайл-тайм вычислений в Н — тут против танка не попрёшь.
Но всё-таки. Вот код из вики:
ExecuteReaderLoop ("SELECT * FROM employee WHERE firstname = $myparm", 
                   dbcon, 
{
  Nemerle.IO.printf ("Name: %s %s\n", firstname, lastname)
});


Здесь макро-навороты очень приятны, всё в пределах основного языка. То, что неявно вводятся переменные — хорошая помогалка.

Или вот:

[PegGrammar(Options = EmitDebugSources, start,
grammar
{  
  any                   = ['\u0000'..'\uFFFF'];
  digit                 = ['0'..'9']+;
  spaces : void         = ' '*;
  
  num                   : int = digit spaces;
  unaryMinus            : int = '-' spaces simplExpr;
  ...
 }
})]
public class CalcParser
{
    private num(digit : NToken) : int
    {
      int.Parse(GetText(digit))
    }
    
    private unaryMinus(_minus : NToken, se : int) : int
    {
      -se
    }
  ...
}


Я больше, чем уверен, что такую сложную штуку как PegGrammar специально дизайнили, чтобы всё гармонично вписывалось в основной язык, который по задумке шарпо-подобен.
Но здесь:
def makeClassInfoPage(cls : Type) : void
    {
      def props = cls.GetProperties();
      def events = cls.GetEvents();
      def title = $"The class <$(cls.Name)>";
      def html = xml <# 
        <html>
          <head>
            <title>$title</title>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> 
            <link rel="stylesheet" href="http://rsdn.ru/css/article.css" type="text/css" />
          </head>
          <body marginwidth="20" marginheight="20">
            <H1>$title</H1>

            <H2 $unless (props.IsEmpty())>Properties</H2>
            <ol $unless (props.IsEmpty())>
              <li $foreach (p in props)>$(p.Name) : $(p.PropertyType)</li>
            </ol>

            <H2 $unless (events.IsEmpty())>Events</H2>
            <ol $unless (events.IsEmpty())>
              <li $foreach (e in events)>$(e.Name) : $(e.EventHandlerType)</li>
            </ol>
          </body>
        </html>
   #>;


уже есть вкрапление "инородного тела". С одной стороны, это лучше, чем просто многострочная строка, но с другой, возможно, было бы приятнее не смешивать коней и людей, и напр., вынести HTML в отдельный файлик со своим языком, где м.б. тоже есть поддержка от IDE, скажем, автокомплит повязан с основным кодом и т.п., плюс всё будет повязано в компайл-тайме как положено. У меня есть подозрение, что часто подобные DSL стараются оформлять отдельным исходником. Приведенный демо-пример не сильно показательный, я пытаюсь сказать, что можно прийти к каше в языке, что-то вроде PHP-лапши.
Например, вроде эрланговцев просят про мета-расширения, но те сопротивляются и кричат не трогайте основной язык, пляшите в сторонке. Имхо, рациональное зерно в этом есть. Конечно есть и положительные моменты, как вкрапления, скажем, регулярных выражений со своим синтаксисом, которые воспринимаются как какие-то бинарные вставки а-ля строковые литералы и т.п.

Короче говоря, есть какие-то явные киллер-причины, когда инопланетный язык в нутрях Немерля самое то ?
Всё-таки кое-каких собак в Н уже поели, может уже есть вылезшие грабли, которые показывают, что лучше всё-таки дсл-ить иногда чуть в сторонке?
Re: Уместны ли внутренние "языки" ?
От: catbert  
Дата: 15.02.12 18:00
Оценка:
PSV>Короче говоря, есть какие-то явные киллер-причины, когда инопланетный язык в нутрях Немерля самое то ?
PSV>Всё-таки кое-каких собак в Н уже поели, может уже есть вылезшие грабли, которые показывают, что лучше всё-таки дсл-ить иногда чуть в сторонке?

Я так с Бейсика делал, граблей особых не замечаю.

Иногда удобнее использовать отдельные файлы
Автор: VladD2
Дата: 09.02.10
, иногда таки писать прямо в коде.
Re: Уместны ли внутренние "языки" ?
От: Ziaw Россия  
Дата: 16.02.12 03:08
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>Но здесь:

PSV>уже есть вкрапление "инородного тела". С одной стороны, это лучше, чем просто многострочная строка, но с другой, возможно, было бы приятнее не смешивать коней и людей, и напр., вынести HTML в отдельный файлик со своим языком, где м.б. тоже есть поддержка от IDE, скажем, автокомплит повязан с основным кодом и т.п., плюс всё будет повязано в компайл-тайме как положено. У меня есть подозрение, что часто подобные DSL стараются оформлять отдельным исходником. Приведенный демо-пример не сильно показательный, я пытаюсь сказать, что можно прийти к каше в языке, что-то вроде PHP-лапши.
PSV>Например, вроде эрланговцев просят про мета-расширения, но те сопротивляются и кричат не трогайте основной язык, пляшите в сторонке. Имхо, рациональное зерно в этом есть. Конечно есть и положительные моменты, как вкрапления, скажем, регулярных выражений со своим синтаксисом, которые воспринимаются как какие-то бинарные вставки а-ля строковые литералы и т.п.

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

PSV>Короче говоря, есть какие-то явные киллер-причины, когда инопланетный язык в нутрях Немерля самое то ?

PSV>Всё-таки кое-каких собак в Н уже поели, может уже есть вылезшие грабли, которые показывают, что лучше всё-таки дсл-ить иногда чуть в сторонке?

Четких критериев в нашей работе очень мало. Немерл полезен тем, что если DSL оказывается проще — мы его используем. Например для создания миграций БД https://github.com/Ziaw/nor/blob/master/Demo/NRails.Dinner/Migrations/M20100624031121.n это удобнее чем включать SQL текст и читаемее чем fluent DSL.
Re[2]: Уместны ли внутренние "языки" ?
От: PSV100  
Дата: 16.02.12 09:55
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Как и в любом техническом решении здесь есть плюсы и минусы. Для веб приложения, с большим количеством HTML выбирать основным способом генерацию прямо в коде не очень хорошее решение. Зато для отдачи кастомных xml ответов, это может быть оправдано. Это удобнее, чем заводить специальные DTO классы для сериализации, да и выполняться будет, вероятно, быстрее.


Z>Четких критериев в нашей работе очень мало. Немерл полезен тем, что если DSL оказывается проще — мы его используем. Например для создания миграций БД https://github.com/Ziaw/nor/blob/master/Demo/NRails.Dinner/Migrations/M20100624031121.n это удобнее чем включать SQL текст и читаемее чем fluent DSL.


Первые впечатления у меня такие же. Мне доводилось лепить свои язычки и всякие DSL. Также хлебнул опыта, когда поддержка DSL обходится дороже, чем решение проблемы "в лоб", для которой DSL задумывался. Поэтому сейчас ко всякому DSL-строению отношусь крайне настороженно. С Немерле хотелось бы для себя прокачать все плюсы и минусы. В моих задачах, в основном, язычки задумывались для упрощения жизни, себе и другим, когда язык очень простой, с простыми алгоритмическими конструкциями плюс несложные декларативные описания, языком могли без напряга пользоваться те, кто не силён в базовом мэйнстримном хост-языке (это не основная их сфера деятельности), для программирования нужен был только текстовый редактор, для системы достаточно только текстового файла (всё подхватывается автоматом и внедряется самой системой не отходя от кассы). Сейчас назревает нечто подобная задача. Я пока не заметил, есть ли в Немерле какой-нибудь script-mode. В любом случае, как я понимаю, Немерл — язык полного "счастья" — компиляция, компоновка, сборка, запуск/загрузка и т.д., т.е. лёгкости нет (я пока не знаю, окажет ли это существенное влияние для меня). К тому же, Немерлом, как правило, пользуются только немерлисты, которые хотят видеть некий улучшенный C# с функциональными плюшками и возможность расширять язык своими операторами, синтаксическими сахарами и вообще отдельными конструкциями (здесь и плюсы, и проблемные минусы). В основном, как я вижу, стараются быть ближе к C# (или к базовому Немерлу, что-ли), что очень разумно, кому нужно, внедряют сторонние вставки, подобные XML/HTML. Общая тенденция в языке, вроде, такая. Возможно, если наступит счастье и начнут появляться различные бэкенды под разные платформы, то возникнет потребность в некотором ограниченном Немерле. Мне как раз интересен опыт создания упрощённого, лёгкого Немерля, но я пока такого не замечал.
Re[2]: Уместны ли внутренние "языки" ?
От: PSV100  
Дата: 16.02.12 10:16
Оценка:
Здравствуйте, catbert, Вы писали:

C>Я так с Бейсика делал, граблей особых не замечаю.


C>Иногда удобнее использовать отдельные файлы
Автор: VladD2
Дата: 09.02.10
, иногда таки писать прямо в коде.


А Бейсик — внедрялся какой-то полноценный язык или отдельные элементы как синтаксический сахар (типа указанного оператора play), и это было решение прикладных проблем (неважно каких именно) или изучение/тренировка/развлечение ?

Почему я так спрашиваю — объяснил чуть ниже
Автор: PSV100
Дата: 16.02.12
в соседнем сообщении.
Re[3]: Уместны ли внутренние "языки" ?
От: Ziaw Россия  
Дата: 16.02.12 10:56
Оценка:
Здравствуйте, PSV100, Вы писали:

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


Согласен. Но лепить DSL в языке для этого не предназначенном похоже на применение ООП с наследованием в чистом С. Создание и поддержка DSL в Nemerle существенно дешевле.

PSV>С Немерле хотелось бы для себя прокачать все плюсы и минусы.


Плюсы станут очевидны если немного попробовать. Минусы тут не единожды обсуждались. Док по тонким моментам мало, можно напороться на баг компилятора. Хотя конкретно эти минусы сейчас уже менее актуальны. Дока разрастается, шоу-стоппер баги давно не появлялись.

PSV>Я пока не заметил, есть ли в Немерле какой-нибудь script-mode. В любом случае, как я понимаю, Немерл — язык полного "счастья" — компиляция, компоновка, сборка, запуск/загрузка и т.д., т.е. лёгкости нет (я пока не знаю, окажет ли это существенное влияние для меня).


Компилятор менеджед. Им легко создать сборку в памяти и запустить ее на выполнение. Посмотри на NPad.

PSV>К тому же, Немерлом, как правило, пользуются только немерлисты, которые хотят видеть некий улучшенный C# с функциональными плюшками и возможность расширять язык своими операторами, синтаксическими сахарами и вообще отдельными конструкциями (здесь и плюсы, и проблемные минусы). В основном, как я вижу, стараются быть ближе к C# (или к базовому Немерлу, что-ли), что очень разумно, кому нужно, внедряют сторонние вставки, подобные XML/HTML. Общая тенденция в языке, вроде, такая. Возможно, если наступит счастье и начнут появляться различные бэкенды под разные платформы, то возникнет потребность в некотором ограниченном Немерле. Мне как раз интересен опыт создания упрощённого, лёгкого Немерля, но я пока такого не замечал.


Встраиваемый в язык DSL естественно не может быть упрощен. Я так понимаю, вам придется сделать парсер своей грамматики, строящий AST nemerle и встроить его в макрос. Это совсем не сложно, если не требуется поддержка IDE. Другой вариант использовать грамматику nemerle (или C#), но обернуть код в макрос, который выдаст ошибку, если используются недопустимые конструкции.
Re: Уместны ли внутренние "языки" ?
От: matumba  
Дата: 16.02.12 17:41
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>... по поводу дизайна всяких своих DSL... пытаюсь сказать, что можно прийти к каше в языке, что-то вроде PHP-лапши.


DSL имеет смысл создавать, когда его ожидается много. А когда его много, сам DSL становится основным языком с вкраплениями Немерлы. Так что проблем не наблюдается. Кроме того, "свой ДСЛ" — лишь возможность, можно оставаться полностью в рамках базового языка.
Re[4]: Уместны ли внутренние "языки" ?
От: PSV100  
Дата: 16.02.12 20:06
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Компилятор менеджед. Им легко создать сборку в памяти и запустить ее на выполнение. Посмотри на NPad.


Спасибки, посмотрю на досуге.

Z>Встраиваемый в язык DSL естественно не может быть упрощен. Я так понимаю, вам придется сделать парсер своей грамматики, строящий AST nemerle и встроить его в макрос. Это совсем не сложно, если не требуется поддержка IDE. Другой вариант использовать грамматику nemerle (или C#), но обернуть код в макрос, который выдаст ошибку, если используются недопустимые конструкции.


Хз, наверное, как-то так, мне с Немерлом ещё разбираться надо. Спасиб.
Re[2]: Уместны ли внутренние "языки" ?
От: PSV100  
Дата: 16.02.12 20:10
Оценка:
Здравствуйте, matumba, Вы писали:

M>DSL имеет смысл создавать, когда его ожидается много. А когда его много, сам DSL становится основным языком с вкраплениями Немерлы. Так что проблем не наблюдается. Кроме того, "свой ДСЛ" — лишь возможность, можно оставаться полностью в рамках базового языка.


Фактически свой язык и нужен, но проще, чем Немерля. Слава богу, что здесь не завалили криминалом и багами по этому поводу. Будем чего-то кумекать. Спасибо.
Re[3]: Уместны ли внутренние "языки" ?
От: WolfHound  
Дата: 17.02.12 09:53
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>Фактически свой язык и нужен, но проще, чем Немерля. Слава богу, что здесь не завалили криминалом и багами по этому поводу. Будем чего-то кумекать. Спасибо.

Немерле умеет компилировать C#.
Можно пойти тем же путем, но грамматику задать какую тебе надо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Уместны ли внутренние "языки" ?
От: catbert  
Дата: 17.02.12 11:48
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>А Бейсик — внедрялся какой-то полноценный язык или отдельные элементы как синтаксический сахар (типа указанного оператора play), и это

было решение прикладных проблем (неважно каких именно) или изучение/тренировка/развлечение ?

Я имел в виду что в Бейсике есть встроенные DSL. Раз уж в Бейсике они не составляют проблем, то в более продвинутых языках проблем тоже не должно быть. Вот веб-ребята часто четыре языка в один файл лепят.

PSV>Почему я так спрашиваю — объяснил чуть ниже
Автор: PSV100
Дата: 16.02.12
в соседнем сообщении.


Насколько я понял вопрос — есть ли подводные грабли во встроенных DSL? Лично я пользовался ими недостаточно, чтобы говорить что-нибудь в общем. Каждый конкретный встроенный язык имеет свои мелкие проблемы (это не считая проблем, которые он решает).

Можно разве что выделить худшую поддержку интеллисенса по сравнению с "базовым" языком. Еще, есть неприятный момент, что DSL это все-таки не Немерле. Допустим, внутри тех же литералов не работает паттерн-матчинг, нужно его выносить вовне, что раздражает. Иногда в PEG-грамматике хочется написать foreach, а его нету, что раздражает.

Но это не какие-то глубокие проблемы, а скорее именно раздражение, что нельзя использовать всю мощь языка.
Re[4]: Уместны ли внутренние "языки" ?
От: PSV100  
Дата: 17.02.12 13:10
Оценка:
Здравствуйте, catbert, Вы писали:

C>Я имел в виду что в Бейсике есть встроенные DSL. Раз уж в Бейсике они не составляют проблем, то в более продвинутых языках проблем тоже не должно быть. Вот веб-ребята часто четыре языка в один файл лепят.


Угу, и вот такой способ от веб-ребятишек лично мне как раз и не приятен. В этом плане более симпатично движение за веб-морды происходит сейчас в кложуре, например. Там уже насмотрелись на много чего, и сейчас пытаются максимально не смешивать коней и людей. Дизайнеры (или их программеры-заместили) могут наваять в сторонке HTML-шаблончик, чистый, без левых примесей, ключевые структуры выделить через div, например. В кложуре файлик парсится, отображается на структуры языка и твори с HTML всё что нужно, всё в рамках "базового" языка и без DSL. Также популярность, вроде, набирают и лёгкие шаблоны типа Mustache или гугловского Ctemplate — т.е. минимум простых инородных тел в HTML-каше.

Поэтому меня интересует, какой есть типичный Nemerle-way для DSL, т.е. к какому дизайну часто приходят DSL-строители и на какой путь направляет немерл, ведь он не сверх-универсальный и не резиновый, ограничения имеет, плюс сам Net тоже вставляет палки в колеса. Пока, в основном, я вижу направление в расширении самого базового языка (в какой-то мере, это скрытый некий DSL) плюс какие-то литеральные вставки а-ля XML (естественно, никто не запрещает также парсить для себя любой текст в сторонке и т.п.).
А также ...

C>Насколько я понял вопрос — есть ли подводные грабли во встроенных DSL? Лично я пользовался ими недостаточно, чтобы говорить что-нибудь в общем. Каждый конкретный встроенный язык имеет свои мелкие проблемы (это не считая проблем, которые он решает).


C>Можно разве что выделить худшую поддержку интеллисенса по сравнению с "базовым" языком. Еще, есть неприятный момент, что DSL это все-таки не Немерле. Допустим, внутри тех же литералов не работает паттерн-матчинг, нужно его выносить вовне, что раздражает. Иногда в PEG-грамматике хочется написать foreach, а его нету, что раздражает.


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


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

P.S. Сорри за то, что не могу чётко сформулировать конкретные вопросы, я ещё толком не знаю, с какой стороны подойти к своей проблеме, и о Немерле хоть и давно знаю, но на уровне прощупывания.
Сеньк за свое оказанное внимание.
Re[4]: Уместны ли внутренние "языки" ?
От: PSV100  
Дата: 17.02.12 13:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Немерле умеет компилировать C#.

WH>Можно пойти тем же путем, но грамматику задать какую тебе надо.

На это я уже обратил внимание, о технической стороне я пока не в курсе, со всем ещё нужно разбираться. Спасибо.
Re[5]: Уместны ли внутренние "языки" ?
От: Ziaw Россия  
Дата: 17.02.12 14:47
Оценка:
Здравствуйте, PSV100, Вы писали:

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


C>>Я имел в виду что в Бейсике есть встроенные DSL. Раз уж в Бейсике они не составляют проблем, то в более продвинутых языках проблем тоже не должно быть. Вот веб-ребята часто четыре языка в один файл лепят.


PSV>Угу, и вот такой способ от веб-ребятишек лично мне как раз и не приятен. В этом плане более симпатично движение за веб-морды происходит сейчас в кложуре, например. Там уже насмотрелись на много чего, и сейчас пытаются максимально не смешивать коней и людей. Дизайнеры (или их программеры-заместили) могут наваять в сторонке HTML-шаблончик, чистый, без левых примесей, ключевые структуры выделить через div, например. В кложуре файлик парсится, отображается на структуры языка и твори с HTML всё что нужно, всё в рамках "базового" языка и без DSL. Также популярность, вроде, набирают и лёгкие шаблоны типа Mustache или гугловского Ctemplate — т.е. минимум простых инородных тел в HTML-каше.


Ну это бабушка надвое сказала. Еще очень популярен knockout, который вводит DSL, смешивает кучу языков в одном файле, зато позволяет получить более простой, понятный и поддерживаемый код минимумом движений. И slim/haml, в которых html совсем не похож на html. Тот же CoffeeScript, который, всего-лишь DSL для JavaScript. Less — DSL для css. Как раз в вебе DSL работают на ура, ибо на том, что там есть писать не слишком удобно, а поменять никак нельзя.

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


Самый главный неприятный момент для DSL — расширение синтаксиса очень ограниченно. По большому счету, нормально работает только расширение синтаксиса выражений. И то, только так, чтобы новый синтаксис был способен пройти через парсер немерла (это, кстати, и плюс тоже). При выходе за рамки метода, DSL-строение терпит крах. Написать linq тоже не получится. В таких случаях приходится DSL загонять в строку и парсить его. Хотя в том же руби, очень популярен вызов мета-методов в теле класса, которые, так сказать, выстраивают сам класс из нужных кубиков. В немерле для этого применяются макроатрибуты, не могу сказать, что это добавляет читабельности.

Еще проблема — кроме собственно компиляции, надо много думать о том, как этот DSL будет вести себя в IDE, в некоторых случаях, достичь интелисенса в своих конструкциях не так-уж просто.

Для решения этих проблем проектируется Н2. Так сказать DSL для создания нужного нам языка.
Re[6]: Уместны ли внутренние "языки" ?
От: PSV100  
Дата: 17.02.12 17:09
Оценка:
Здравствуйте, Ziaw, Вы писали:

PSV>>Угу, и вот такой способ от веб-ребятишек лично мне как раз и не приятен. В этом плане более симпатично движение за веб-морды происходит сейчас в кложуре, например. Там уже насмотрелись на много чего, и сейчас пытаются максимально не смешивать коней и людей. Дизайнеры (или их программеры-заместили) могут наваять в сторонке HTML-шаблончик, чистый, без левых примесей, ключевые структуры выделить через div, например. В кложуре файлик парсится, отображается на структуры языка и твори с HTML всё что нужно, всё в рамках "базового" языка и без DSL. Также популярность, вроде, набирают и лёгкие шаблоны типа Mustache или гугловского Ctemplate — т.е. минимум простых инородных тел в HTML-каше.


Z>Ну это бабушка надвое сказала. Еще очень популярен knockout, который вводит DSL, смешивает кучу языков в одном файле, зато позволяет получить более простой, понятный и поддерживаемый код минимумом движений. И slim/haml, в которых html совсем не похож на html. Тот же CoffeeScript, который, всего-лишь DSL для JavaScript. Less — DSL для css. Как раз в вебе DSL работают на ура, ибо на том, что там есть писать не слишком удобно, а поменять никак нельзя.


Я с вебом мало повязан, но в курсе, что всяких DSL-ей там до хрена, и не от хорошей жизни.
Например, тот же дизайнер у себя может наваять haml, но программеру выдать готовый стандартный HTML, и тому не придётся у себя дсл-ить вокруг всякого haml. Т.е. я лишь хотел подчеркнуть, что если язык/платформа меньше нагибает ко всякому DSL-выплясыванию — тем проще жить (кстати, когда-то на глаза попадалось то, что немерлисты хотели бы у себя эмулировать и этот knockout, и, если я не ошибаюсь, как раз в рамках проекта немерлевских рельс, где вы, как я понял, не последний человек. И вроде есть тенденция к аналогу СlojureScript — т.е. как бы как раз стремление к уменьшению внешнего "DSL").

Z>Самый главный неприятный момент для DSL — расширение синтаксиса очень ограниченно. По большому счету, нормально работает только расширение синтаксиса выражений. И то, только так, чтобы новый синтаксис был способен пройти через парсер немерла (это, кстати, и плюс тоже). При выходе за рамки метода, DSL-строение терпит крах. Написать linq тоже не получится. В таких случаях приходится DSL загонять в строку и парсить его.


У меня как раз такие чувства, что в Н, прежде всего, пока всё направлено на расширение синтаксиса базового языка, остальное — побочный эффект от таких возможностей. Как-то так.

Z>Хотя в том же руби, очень популярен вызов мета-методов в теле класса, которые, так сказать, выстраивают сам класс из нужных кубиков. В немерле для этого применяются макроатрибуты, не могу сказать, что это добавляет читабельности.


Верно подмечено по поводу атрибутов. И в джаве аннотации, и в питоне декораторы — выглядят всё-таки немного инородными для языка (речь не о функционале).
А в таких языках, как руби, всё-таки в основном, всё вертится вокруг динамических типов и ран-тайм вызовов. Но ран-тайм иногда действительно тот момент, когда в этом есть необходимость. Я мало смотрел немерлевского кода, но я не видел нечто подобного как GPath в груви (возможно это вполне эмулируется). Кстати, в том же груви их командные цепочки или как их там (сommand chains) — отличная простая штука без всяких парсеров, в немерле не видел (опять же, может и есть).

Z>Еще проблема — кроме собственно компиляции, надо много думать о том, как этот DSL будет вести себя в IDE, в некоторых случаях, достичь интелисенса в своих конструкциях не так-уж просто.

Z>Для решения этих проблем проектируется Н2. Так сказать DSL для создания нужного нам языка.

Про Н2 слышал/читал. Единственное, что хотелось бы сказать, как простому смертному — хотелось бы по-проще. Тот же MetaLua — как-то по-человечнее что ли (понимаю, что функционал не тот). Будь по-проще, и народ потянется

Спасибо за практичную инфу.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.