Языково-ориентированное программирование

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

Языково-ориентированное программирование (ЯОП) (англ. Language Oriented Programming), также Расходящаяся разработка (англ. middle out development), также метаязыковая абстракция[en], также Разработка, опирающаяся на предметно-специфичный язык (англ. DSL-Based Development)[1]парадигма программирования, заключающаяся в разбиении процесса разработки программного обеспечения на стадии разработки предметно-ориентированных языков (DSL) и описания собственно решения задачи с их использованием. Стадии могут вестись последовательно или параллельно, однократно или рекурсивно[2][1]; DSL могут быть реализованы зависимо или независимо от базового языка[⇨] и иметь одну или множество реализаций.

Место и роль в информатике[править | править вики-текст]

ЯОП предназначено для разделения сложностей: машино-ориентированная часть кода (низкоуровневая функциональность) и человеко-ориентированная (собственно решение прикладной задачи) разрабатываются независимо друг от друга, что исключает экспоненциальный рост результирующей сложности разработки всего проекта и решает проблему сложности как фундаментальную проблему программирования[2], описанную Фредериком Бруксом в знаменитом эссе «Серебряной пули нет», из-за которой оказывается невозможно простым совершенствованием рабочего инструментария повысить производительность труда программистов даже на порядок. Из этого же прямо следует большинство остальных преимуществ[⇨].

О достоинствах сужения специализации языков говорили ещё в середине 1980-х[3], а о достоинствах повышения уровня языков — намного раньше[4], но DSL-ориентированная разработка сформировалась как самостоятельная методология лишь к середине 1990-х[⇨].

Использование DSL вместо языков общего назначения существенно повышает уровень абстрактности кода, что позволяет вести разработку быстро и эффективно и создавать программы, которые легки в понимании и сопровождении; а также делает возможным или существенно упрощает решение многих задач, связанных с манипулированием программами (порождение программ, исследование определённого свойства программ — корректности, эффективности и др.)[3][1][5][6]. С другой стороны, разработка нового языка и эффективная его реализация является нетривальной проблемой теоретической и прикладной информатики[⇨].

Среди прочих подходов к проектированию программ ЯОП выделяется гораздо более агрессивной направленностью на приближение компьютера к человеку. Среди исследователей ЯОП бытует мнение, что в наукоёмких задачах хорошо спроектированный и реализованный DSL делает общение человека с компьютером куда более удобным и продуктивным, чем графический интерфейс пользователя. В качестве примеров чаще всего приводятся следующие популярные предметно-специфичные языки:

и др.

Сравнение ЯОП с традиционным подходом

Преимущества ЯОП проявляются даже в тех случаях, когда DSL разрабатывается не для массового использования, а для решения единственной задачи. Например, при разработке системы автоматического эквивалентного преобразования программ FermaT[en] переход от «плоского» программирования на Лиспе к рекурсивному ЯОП (на Лиспе был реализован язык WSL, на нём — язык MetaWSL, а уже на нём — целевая функциональность) не только позволил сократить общий объём кода со 100 до 16 тысяч строк, но одновременно повысил все основные качественные характеристики кода и даже сделал возможным решение задач, которые иначе решить не удавалось[2].

Упрощённо сравнить рост трудозатрат при использовании традиционного и языково-ориентированного подходов позволяет график[1]. Как видно, ЯОП оказывается целесообразно лишь начиная с некоторого порога объёма и сложности функциональности целевой системы.

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

В мейнстриме часто применяется встраивания интерпретатора в язык общего назначения (см. Подход), хотя это делается не только без апелляции к принципам ЯОП, но и зачастую без осознания факта её применения как таковой. Наиболее часто встраиваются: язык регулярных выражений (интерпретатор PCRE), Lua, SQL, XML. Также был разработан инструментарий визуального программирования для использования в мейнстриме некоторых идей ЯОП.

Многие исследователи видят цель ЯОП в том, чтобы полностью размыть границы между математической моделью и её реализацией на ЭВМ и сделать возможной разработку программного обеспечения специалистами предметных областей, не имеющими специфичных знаний в программировании[1][6]:

-- проверка вхождения точки в регион:
inRegion :: Point -> Region -> Bool
p ‘inRegion‘ r = r p

...
Благодаря точному запечатлению семантики предметной области даже не-программисты оказываются способны понять значительную часть кода. В эксперименте, проведённом по заказу Naval Surface Warfare Center, совершенно незнакомые с Хаскелом люди схватывали основные понятия на лету. Некоторые даже выразили неверие в то, что этот код был действительно исполнимым.
(В самом деле, не смотря на присутствие в тексте этого последнего предложения, один из рецензентов первого черновика данной работы выразил недовольство тем, что «работа заявляется как рассуждения одновременно о синтаксисе и семантике, но её содержание в основном касается синтаксиса (как, например, определение inRegion), и не делается никаких различий между математикой и программированием». Но на самом деле, это определение inRegion целиком и полностью семантическое. Более того, эквациональные рассуждения[7] ... позволяют размыть грань между математикой и программированием: программы могут рассматриваться как спецификации. Это особое свойство, так как расширяет применение формальных методов.)

— Paul Hudak, «Modular Domain Specific Languages and Tools»[1]

Подход[править | править вики-текст]

В основе подхода лежит идея о том, что язык, специально разработанный под поставленную задачу, будет обеспечивать заведомо более высокие показатели качества кода, чем любой язык общего назначения[1][6], и что для решения сложных промышленных задач более эффективным будет изобрести более простой в понимании (человеко-ориентированный[8] или точно инкапсулирующий предметные знания[2][1]) язык, нежели преодолевать трудности использования имеющегося, даже укоренившегося в промышленности[4].

Большинство исследователей говорят о ЯОП как о переводе всей индустрии разработки ПО на использование текстовых языков 4-го и 5-го поколения[8], но некоторые ориентируются на использование визуальных языков[9][10].

Основные проблемы подхода состоят в нахождении способов быстро создать реализацию придуманного DSL, чтобы начать разрабатывать собственно решение задачи, и в обеспечении хорошей вычислительной производительности DSL.

Предметно-ориентированный язык, как и вообще любой язык программирования, определяется алфавитом, грамматикой, семантикой и психолингвистикой, однако, в зависимости от способа реализации DSL, роль и взаимосвязь этих уровней может размываться и/или наследоваться от языка его реализации.

Разные авторы делают акцент на разных способах разработки предметно-специфичных языков:

При использовании макросредств, в свою очередь, различают шаблонное метапрограммирование и многостадийную статическую интерпретацию[13][17][18][5].

Третий и четвёртый методы имеют фундаментальное преимущество перед первыми двумя — DSL не заменяет, а расширяет язык общего назначения[14][1][19][20], повторно используя весь инструментарий базового языка, начиная с парсера, благодаря чему:

  • появляется возможность комбинировать в едином коде возможности базового языка, общих библиотек к нему, разработанного предметно-специфичного языка и даже нескольких других разработанных аналогичным образом предметно-специфичных языков, применяя устоявшиеся для базового языка идиомы, трюки, скрещивая методологии;
  • устраняется необходимость реализовывать с нуля тривиальные вещи (такие как арифметика чисел) — достаточно адаптировать синтаксис;
  • устраняется необходимость разработки полного комплекса инструментария разработки (оптимизирующего транслятора с информативными сообщениями об ошибках, REPL, отладчика, профилировщика и пр.). При рекурсивном встраивании DSL повторное использование кода достигает гигантских масштабов[1].

Многие авторы состредотачиваются на эффективном (без интерпретации) встраивании в язык определённых изначально отсутствующих в нём возможностей для адаптации к определённым задачам[15][21], что в дальнейшем может служить основой для чистого встраивания DSL[22]. Значительное внимание уделяется использованию продолжений для разработки DSL с недетерминированной семантикой (Стил[en], Уэнд[en], Феллейзен[en], Рэмси[en], Реппи[en] и другие).

Приложения подхода и самоприменимость[править | править вики-текст]

Важным подвидом ЯОП является Пользовательское программирование[en], позволяющее самым разным людям, не имеющим никакого представления об информатике, эффективно решать множество прикладных задач. Роль этого приложения ЯОП столь велика, что едва ли не самым распространённым в мире языком программирования на практике оказываются средства вёрстки крупноформатных таблиц (англ. spreadsheets)[6].

В зависимости от трактовки термина «метапрограммирование» (МП) и способа реализации DSL, либо ЯОП является квинтэссенцией МП, либо МП служит одним из способов реализации ЯОП. Последний вариант наиболее применим в случае встраивания DSL в язык общего назначения посредством макро-подмножества последнего[13]. При использовании средств визуальной разработки DSL[9][10] эти определения оказываются синонимичными, т.к. само визуальное программирование представляет собой простейшую форму МП. Рассмотрение МП в качестве самоприменения ЯОП означает:

  • для встраиваемых DSL — рекурсивное применение ЯОП, предлагаемое Уордом и Хьюдаком;
  • для независимых DSL — раскрутку компилятора (англ. bootstrapping).

Инструментарий[править | править вики-текст]

Для разработки независимых трансляторов широко распространены генераторы лексеров и парсеров на основе определения грамматики целевого DSL посредством БНФ и регулярных выражений:

и другие.

При компиляции независимого DSL целевой платформой редко выбирается машинный код или даже Ассемблер, более предпочтительным (как для снижения трудоёмкости реализации DSL, так и для повышения портируемости) является использование платформы более высокого уровня:

  • языка общего назначения высокого уровня;
  • языка общего назначения среднего уровня (Си, BitC[en], Forth)
  • промежуточного языка или фреймфорка компиляторов (C--, MLRISC[24])
  • низкоуровневой виртуальной машины (LLVM)

Для встраивания DSL в язык общего назначения используются следующие технологии:

Чистое встраивание не предполагает каких-либо дополнительных инструментов, но накладывает довольно жёсткие ограничения на выбор базового языка[⇨].

При использовании многостадийной статической интерпретации целевая платформа совпадает с базовым языком[13][17][18][5].

В рамках традиционного программирования (на языках, наследованных от Алгола) использование некоторых идей ЯОП делает возможным инструментарий визуального программирования, разработанный в первой половине 2000-х годов[9][10][28][29]:

  • Intentional Software, Meta Programming System (JetBrains)[30]

История, философия, терминология[править | править вики-текст]

В сообществе языка Lisp практически от момента создания практиковалось использование макросредств для адаптации к требованиям предметной области задачи. Этот подход, в частности, был подробно описан в книге Структура и интерпретация компьютерных программ. Аналогичные идеи временами применялись в сообществе языка Forth. В основном эти решения носили спонтанный характер, и зачастую их можно классифицировать как ad hoc-решения[13].

Во второй половине 1970-х годов была изобретена система типов Хиндли — Милнера, которая легла в основу языка ML (аббревиатура от «MetaLanguage» — рус. МетаЯзык). Изначально ML разрабатывался в качестве DSL для системы автоматического доказательства теорем LCF[en], но вскоре стало ясно, что он может быть хорошим прикладным языком общего назначения — более качественным, чем языки, изначально проектируемые быть языками общего назначения, т.к. отлажен на одной конкретной сложной задаче[31][32]. Как следствие, он породил целое семейство Х-М-типизированных языков, завоевавших популярность в качестве языков для разработки языков (метаязыков) и часто определяемых как «DSL для денотационной семантики[en]»[1].

В 1994 году Мартин Уорд (англ. Martin Ward)[33] дал подробную характеристику методологии[2] и предложил термины «языково-ориентированное программирование» и «расходящаяся разработка» (или «разработка от центра к краям», middle out development), отметив, что подход в разнообразных формах неоднократно применялся ранее. Термин «расходящаяся разработка» подчёркивает, что средним слоем (middle layer) в результирующей системе является разработанный DSL,— в противовес ранее известным и широко до сих пор применяющимся методам «восходящей разработки» (bottom up development[en]), «нисходящей разработки» (top down development[en]) и совмещающей их «сходящейся разработки» (ouside in development).

Уорд также предложил использовать ЯОП рекурсивно, поэтапно наращивая сложность разрабатываемой системы снизу вверх; и сочетать ЯОП с быстрым прототипированием, разрабатывая сперва простейший прототип DSL (что может быть выполнено очень быстро) и простейшее решение с его использованием, затем, после тестирования языка, выявления недочётов и уточнения требований, дорабатывать DSL и переписывать решение на новой версии языка, и так далее итеративно.

Пол Хьюдак[en] предложил[1] метод чистого встраивания (англ. pure embedding) с применением типобезопасных[en] языков (предпочтительно ленивых, таких как Haskell, но возможно и строгих, таких как ML, хотя в последнем случае реализация выходит несколько более громоздкой и менее естественной) и эквациональные рассуждения[7], рекурсивно разрабатывая систему сверху вниз и накапливая повторно используемый код в виде «DSL для разработки DSL».

Метод чистого встраивания породил термин «встраиваемый предметно-специфичный язык» (англ. Embedded DSL, EDSL; иногда DSEL)[1][8]. Был разработан целый ряд EDSL над Хаскелем для программирования в чистом функциональном стиле интерактивных приложений реального времени (Fran, Fruit, FRP и RT-FRP, FAL, Frob, Fvision, Yampa)[34][19], сформировавших самостоятельную парадигму — функциональное реактивное программирование (ФРП). Это показывает, что ЯОП не является отдельной замкнутой парадигмой программирования, а напротив, может использоваться в качестве инструмента при разработке новых парадигм.

Вокруг Standard ML — базового диалекта ML — с начала 1990-х годов велись споры в отношении отсутствия макросредств в языке[31]. Критики утверждали, что отсутствие макросредств является недостатком, но сторонники строгой типизации возражали, что их отсутствие является как раз преимуществом. В другом диалекте ML — OCaml — была предложена компромиссная идея — параметризация синтаксиса за счёт выделения парсера в настраиваемый модуль CamlpX[en] компилятора, посредством которой было разработано множество EDSL для OCaml. Позже появилось расширение для генерации кода во время выполнения[en]MetaOCaml[en]. В конце 1990-х годов была предложена идея типобезопасных[en] макросредств как инструмента эффективной реализации типобезопасных DSL[35]. Эту идею вскоре воплотили в виде расширений MetaML[13][17][18] — для языка Standard ML и Template Haskell[en][36] — для языка Haskell. В первом случае макросредства рассматриваются исключительно как многостадийный статический интерпретатор; во втором они рассматриваются одновременно и как этот же подход, и как известное из языка Lisp квазицитирование, и как подсистема шаблонов, аналогичная имеющейся в языке C++.

Исследование возможности реализации и применения этих подходов в разных языках показали, что С++ является крайне неудобным инструментом разработки встраиваемых языков[37]. Тем не менее, С++ позволяет воплощать решения этого направления, культивированные и отлаженные под эгидой функционального программирования[5][38], что для мейнстримных языков является редким достоинством[5].

Данные предварительных исследований, опубликованные в 2012 году, показали, что независимый DSL оказывается удобнее в использовании, в то время как EDSL проще в реализации[8].

Критика и сравнение с альтернативами[править | править вики-текст]

Достоинства[править | править вики-текст]

Рост сложности любой программной системы принципиально ограничен тем пределом, до которого ещё можно сохранять контроль над ней: если объём информации, требуемый для осмысления компонента этой системы, превышает «вместимость» мозга одного человека, то этот компонент не будет до конца понят. Станет чрезвычайно тяжело дорабатывать его или исправлять ошибки, и от каждой корректировки можно ждать введения новых ошибок из-за этого неполного знания.

— Martin Ward, «Language Oriented Programming»[2]

ЯОП имеет множество достоинств перед традиционной «плоской» разработкой[2]:

  • Разделение сложностей. Реализация и собственно решение оказываются полностью независимы, что исключает экспоненциальный рост результирующей сложности разработки всего проекта.
  • Высокая скорость разработки. Всего несколько строк на DSL могут реализовывать очень сложные функции. Реализация DSL также сохраняется простой, так как содержит лишь необходимые функции.
  • Высокая модифицируемость. Исследования, на которые ссылается Мартин Уорд, показывают, что самым важным фактором, обусловливающим трудности модификации системы, является размер кода. Разделение логики и реализации и сокращение общего объёма кода существенно упрощают его модификацию и исправление ошибок. При традиционном подходе принятые решения по реализации оказываются «размазанными» по проекту, что затрудняет понимание зависимостей (решений, которые привели к написанию данного участка кода). Сторонники «модульного проектирования» приводят те же аргументы, но более фундаментальные проектные решения обычно не могут быть инкапсулированы в одном модуле.
  • Существенное увеличение коэффициента повторного использования кода. DSL, инкапсулирующий специфичные знания предметной области, может быть повторно использован для решения задач одного класса, в т.ч. для самой задачи разработки DSL[2][1].
  • Существенное упрощение портирования системы. Необходимо переделывать только реализацию DSL, тогда как логика системы (код на DSL) переносится без изменений. В случае с FermaT[en], реализация DSL нижнего уровня занимала всего 2-3 тысячи строк кода на Lisp, и в дальнейшем была переписана на Си всего за три человеко-дня. Другим примером служит высокая портируемость системы ΤΕΧ. Кроме того, после создания прототипа реализации DSL дальнейшая разработка приложения может быть распараллелена — одни разработчики занимаются решением прикладной задачи, в то время как другие независимо от них реализуют DSL на разных платформах и совершенствуют эти реализации.
  • Принципиальная возможность решения задач. Многие подзадачи не удавалось решить посредством классического подхода из-за превышения общей сложности решения возможностей человека по восприятию и переработке информации. Решение же на DSL оказывается не просто возможным, а очень простым и интуитивным, к тому же исключающим размножение ошибок, так как доступ к очень сложным функциям системы осуществляется через примитивы DSL.
  • Получение программных систем, расширяемых их пользователями[6]. DSL делает программирование доступным для специалистов предметной области, не имеющих специфичных знаний в программировании, и даёт им возможность самостоятельно расширять функциональность системы, что принципиально невозможно при использовании традиционного подхода.

Реализация языков путём разработки независимых трансляторов является рутинной задачей, так как накоплена обширная формальная база и основанного на ней инструментария (Lex/Yacc, ANTLR, Parsec[23]). Например, на Parsec разработка парсеров для языков с несложной грамматикой (сопоставимой с грамматикой Паскаля Вирта) выполняется за считанные человеко-часы[39][40].

Недостатки[править | править вики-текст]

Языково-ориентированное программирование имеет два основных недостатка перед традиционным, которые, однако, не являются фундаментальными: высокий порог вхождения для разработчиков языков (снижаемый ценой отказа от большинства преимуществ методологии) и трудности обеспечения вычислительной производительности. Оба недостатка актуальны лишь для разработчиков предметно-специфичных языков; пользователи языка (прикладные специалисты) получают чистые преимущества.

Ограничения[править | править вики-текст]

Для разработки новых языков требуется хорошая теоретическая подготовка и свободное владение семантически разными языками и их расширениями. Мартин Уорд отмечает, что проектирование хорошего языка, потенциально способного удовлетворять его пользователей и иметь длительный жизненный цикл — это сложная задача, требующая высокой степени грамотности в информатике, и рекомендует программистам постоянно практиковаться в разработке языков для накопления достаточного практического опыта. Кроме того, он указывает, что назначение ЯОП не в том, чтобы снизить порог вхождения для разработчиков, а наоборот, в том, чтобы расширить возможности и упростить работу квалифицированных разработчиков,— а уже в дальнейшем это приводит к снижению порога вхождения пользователей системы, необходимого для её использования и развития.

Методы встраивания DSL в язык общего назначения применимы далеко не в любом языке, т.к. требуют определённых свойств семантики базового языка в разных сочетаниях: аппликативной модели вызова, истинно полиморфной системы типов либо динамической типизации (см. полиморфизм), функций высшего порядка, продолжений, развитой подсистемы макрорасширения, рефлексивности, ленивости. Эти свойства доступны изначально (или могут быть полноценно реализованы) далеко не в любом языке. Чаще всего оба метода и их комбинации используются в диалектах языков, основанных на нетипизированном и типизированном лямбда-исчислении (математической модели описания семантик), порой с нестандартизированными специфичными расширениями: Common Lisp, Scheme, Standard ML, MetaML[13], Alice, OCaml, MetaOCaml[en], Haskell, Template Haskell[en], Nemerle. Также эти методы применимы в языке Forth, хотя реально применяются разработчиками на Forth относительно редко. Все эти языки имеют высокий порог вхождения. Некоторые авторы отмечают возможность применения третьего метода в мейнстримном языке С++, но пригодность С++ для ЯОП подвергается критике[37].

Визуальная разработка DSL[9][10] имеет низкий порог вхождения, но жертвует рядом свойств ЯОП, описываемых Уордом, Хьюдаком и другими:

  • Понятие DSL определяется как «урезанный язык программирования (в большинстве случаев не полный по Тьюрингу)»;
  • Рассматриваются DSL только с детерминированной семантикой, в частности, Фаулер относит к DSL адаптивные объектные модели (так что размытие границ между математикой и семантикой, на котором делает акцент Хьюдак, не выполняется);
  • Не рассматриваются возможности ни рекурсивного применения ЯОП, ни увеличения числа реализаций разработанного DSL, так что эффективность реализации DSL целиком зависит от разработчиков визуальной среды.

Эффективность[править | править вики-текст]

Вычислительная производительность «небрежной» реализации DSL может оказаться невысокой, а хорошая оптимизация — неоправданно дорогой. Разумеется, в силу предназначения некоторых DSL, скорость для них не имеет принципиального значения (ΤΕΧ, AutoLisp). В остальных же случаях она зависит как от способа реализации, так и от целевой платформы компиляции, и во многих случаях удаётся добиться очень хороших показателей. Например, Валид Таха описывает[41] реализацию транслятора функционально чистого языка FRP методом порождения императивного кода на Си, с помощью которого были разработаны приложения реального времени для 16-битного микроконтроллера PIC16C66[42]. Хьюдак указывает[1], что многостадийные модульные реализации DSL методом чистого встраивания (см. Подход) в Haskell получаются крайне медлительными, так как каждый слой абстракции даёт 15-70-кратное замедление, — но за счёт применения техники суперкомпиляции скорость может быть обратно повышена на три порядка (от 400 до 2800 раз).

Возможна разработка DSL, предназначенного для оптимизации конструкций, применяемых в логике более высокого уровня. Например, был разработан язык OL (Operator Language)[43] для описания математических алгоритмов платформенно-независимым образом и упрощения портирования на новые архитектуры математических библиотек с высокими требованиями эффективности (см. числодробилка). Компилятор параметризуется данными об архитектуре процессора (поддержке векторных операций, количестве ядер и др.), а также порой выполняет автоматическое сравнительное тестирование вариантов реализации с выбором наиболее быстрой. В результате программа на декларативном ЯСВУ порождает на выходе очень эффективный (сравнимый с написанным вручную) код на Си, реализующий алгоритм максимально эффективным для данной архитектуры образом. В данном случае компонентом эффективности также становится ужесточение размера входных данных — например, может быть построена быстрая функция для перемножения матриц размера 8x8.

Использование встраиваемых DSL в языках, для которых существуют глобально-оптимизирующие компиляторы (такие как Stalin Scheme, MLton), позволяет осуществлять языково-ориентированную декомпозицию задач без потерь эффективности в сравнении с другими подходами к проектированию, но может накладывать ограничения на разрабатываемый DSL. Это направление является предметом многих исследований.

Все эти решения являются частными, и применимость каждого из них зависит от природы разрабатываемого DSL на всех уровнях, либо наоборот, предъявляет к ней особые требования. Таким образом, соотнесение архитектуры проекта с эффективностью его реализации является неотъемлемой частью проблематики ЯОП. Это верно и для других подходов к проектированию, но в гораздо меньшей степени.

Примечания[править | править вики-текст]

  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Hudak - Modular Domain Specific Languages and Tools, 1998
  2. 1 2 3 4 5 6 7 8 Ward - Language Oriented Programming, 1994
  3. 1 2 Bentley - Little languages, 1986
  4. 1 2 Backus - Can Programming Be Liberated from the vonNeumann Style?, 1978, Introduction
  5. 1 2 3 4 5 Czarnecki, O’Donnell, Striegnitz, Taha - DSL implementation in metaocaml, template haskell, and C++, 2004
  6. 1 2 3 4 5 Taha - Domain-Specific Languages, 2008
  7. 1 2 3 Equational reasoning
  8. 1 2 3 4 Mernik - Formal and Practical Aspects of Domain-Specific Languages, 2012
  9. 1 2 3 4 Мартин Фаулер Языковой инструментарий: новая жизнь языков предметной области. — 2005.
  10. 1 2 3 4 Сергей Дмитриев (JetBrains) Языково-ориентированное программирование: следующая парадигма // = RSDN Magazine. — 2005.
  11. Ахо, Сети, Ульман - Компиляторы, 1985
  12. Developing Applications With Objective Caml
  13. 1 2 3 4 5 6 7 Ganz, Sabry, Taha - Macros as Multi-Stage Computations, 2001
  14. 1 2 Shivers - The ultimate little language, 1996
  15. 1 2 Berthomieu - OO Programming Styles in ML, 2000
  16. Ramsey - Embedding an Interpreter, 1990
  17. 1 2 3 Taha - A Gentle Introduction to Multi-stage Programming, 2004
  18. 1 2 3 Taha - A Gentle Introduction to Multi-stage Programming, Part II, 2007
  19. 1 2 Cheong - Functional Programming and 3D Games, 2005
  20. Benton - Embedded Interpreters, 2005
  21. Ramsey - Concurrent Programming in ML, 1990
  22. Schelog, 2003
  23. 1 2 Parsec for Haskell.
  24. MLRISC Library - a framework for retargetable and optimizing compiler back ends
  25. Object Language Embedding in SML with Quote/Antiquote.
  26. Daniel de Rauglaudre. Camlp4 - Tutorial ((c) 2002 Institut National de Recherche en Informatique et Automatique).
  27. Martin Jambon. How to customize the syntax of OCaml, using Camlp5 ((c) 2005, 2010).
  28. Дмитрий Кириллов. Ориентация на язык. Компьютерра (14 марта 2006). Проверено 5 мая 2006.
  29. Игорь Тамащук. Domain Specific Language в своём приложении — это просто (22 октября 2008). Проверено 24 октября 2008. Архивировано из первоисточника 12 февраля 2012.
  30. JetBrains - DSL Development Environment
  31. 1 2 Appel - A Critique of Standard ML, 1992
  32. Paulson - ML for the Working Programmer, 1996, Standard ML, с. 11
  33. Martin Ward's Homepage
  34. Elliott, Hudak - Functional reactive animation, 1997
  35. Bawden - First-class macros have types, 2000
  36. Sheard, S.P.Jones - Template Meta-programming for Haskell, 2002
  37. 1 2 Czarnecki, O’Donnell, Striegnitz, Taha - DSL implementation in metaocaml, template haskell, and C++, 2004, 6. Discussion and Concluding Remarks, с. 18: «C++ Template Metaprogramming suffers from a number of limitations, including portability problems due to compiler limitations (although this has significantly improved in the last few years), lack of debugging support or IO during template instantiation, long compilation times, long and incomprehensible errors, poor readability of the code, and poor error reporting.»
  38. Daniel Lincke, Patrik Jansson, Marcin Zalewski, and Cezar Ionescu Generic Libraries in C++ with Concepts from High-Level Domain Descriptions in Haskell // DSLs, IFIP TC 2 Working Conference. — Oxford, UK: Springer Berlin Heidelberg New York, Germany, 2009. — В. July 15-17, Volume Editor W.M. Taha. — С. 236-261. — ISBN 3-642-03033-5, 978-3-642-03033-8. — ISSN 0302-9743.
  39. Jonathan Tang. Write Yourself a Scheme in 48 Hours.
  40. О том, как на Хаскеле компилировать Паскаль в..
  41. Zhanyong Wan, Walid Taha, Paul Hudak Event-Driven FRP. — Department of Computer Science, Yale University.
  42. PIC16C66 - PIC® Microcontrollers
  43. Franz Franchetti, Frédéric de Mesmay, Daniel McFarlin, and Markus Püschel, Carnegie Mellon University Operator Language: A Program Generation Framework for Fast Kernels // Domain-Specific Languages, IFIP TC 2 Working Conference, International Federation for Information Processing. — Oxford, UK: Springer Berlin Heidelberg New York, Germany, 2009. — В. July 15-17, Volume Editor W.M. Taha. — С. 385–409. — ISBN 3-642-03033-5, 978-3-642-03033-8. — ISSN 0302-9743.

Ссылки[править | править вики-текст]

Литература[править | править вики-текст]

Учебники, руководства, справочники, использование[править | править вики-текст]

История, анализ, критика[править | править вики-текст]