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

Парадигмы программирования

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

Место и роль в информатике

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

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

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

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

и др.

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

Преимущества ЯОП проявляются даже в тех случаях, когда DSL разрабатывается не для массового использования, а для решения единственной задачи. Например, при разработке системы автоматического эквивалентного преобразования программ FermaT[англ.] переход от «плоского» программирования на Лиспе к рекурсивному ЯОП (на Лиспе был реализован язык 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] … позволяют размыть грань между математикой и программированием: программы могут рассматриваться как спецификации. Это особое свойство, так как расширяет применение формальных методов.)

Оригинальный текст (англ.)
...
Because the domain semantics is captured concisely, it is possible even for non-programmers to understand much of the code. In the Naval Surface Warfare Center experiment, those completely unfamiliar with Haskell were able to grasp the concepts immediately. Some even expressed disbelief that the code was actually executable.
(Indeed, despite the presence of this last sentence, one reviewer of the first draft of this paper complained that “the paper claims to be interested in both syntax and semantics, but the presented details are mostly syntactic (e.g., the definition inRegion), and the paper makes no attempt to distinguish mathematical and programmatic entities.” But in fact this definition of inRegion is entirely semantic. Furthermore, equational reasoning[7] ... allows one to blur the distinction between mathematical and programmatic entities: programs can be viewed as specifications. This is a feature, as it enhances the application of formal methods.)
— 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][16], что в дальнейшем может служить основой для чистого встраивания DSL[21]. Значительное внимание уделяется использованию продолжений для разработки DSL с недетерминированной семантикой (Стил[англ.], Уэнд[англ.], Феллейзен[англ.], Рэмси[англ.], Реппи[англ.] и другие).

Приложения подхода и самоприменимость

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

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

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

Инструментарий

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

и другие.

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

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

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

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

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

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

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

История, философия, терминология

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

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

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

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

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

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

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

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

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

Критика и сравнение с альтернативами

Достоинства

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

Оригинальный текст (англ.)
There is a fundamental limit to complexity of any software system for it to be still manageable: if it requires more than "one brainfull" of information to understand a component of the system, then that component will not be understood fully. It will be extremely difficult to make enhancements or fix bugs, and each fix is likely to introduce further errors due to this incomplete knowledge.
— Martin Ward, «Language Oriented Programming»[2]

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

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

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

Недостатки

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

Ограничения

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

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

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

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

Эффективность

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

Возможна разработка DSL, предназначенного для оптимизации конструкций, применяемых в логике более высокого уровня. Например, был разработан язык OL (Operator Language)[42] для описания математических алгоритмов платформенно-независимым образом и упрощения портирования на новые архитектуры математических библиотек с высокими требованиями эффективности (см. числодробилка). Компилятор параметризуется данными об архитектуре процессора (поддержке векторных операций, количестве ядер и др.), а также порой выполняет автоматическое сравнительное тестирование вариантов реализации с выбором наиболее быстрой. В результате программа на декларативном языке сверхвысокого уровня порождает на выходе очень эффективный (сравнимый с написанным вручную) код на Си, реализующий алгоритм максимально эффективным для данной архитектуры образом. В данном случае компонентом эффективности также становится ужесточение размера входных данных — например, может быть построена быстрая функция для перемножения матриц размера 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. Дата обращения: 26 ноября 2013. Архивировано 12 ноября 2013 года.
  8. ↑ 1 2 3 4 Mernik - Formal and Practical Aspects of Domain-Specific Languages, 2012.
  9. ↑ 1 2 3 4 Мартин Фаулер. Языковой инструментарий: новая жизнь языков предметной области. — 2005. Архивировано 26 декабря 2013 года.
  10. ↑ 1 2 3 4 Сергей Дмитриев (JetBrains). Языково-ориентированное программирование: следующая парадигма // = RSDN Magazine. — 2005. Архивировано 23 марта 2010 года.
  11. ↑ Ахо, Сети, Ульман, 1985, 2001, 2003.
  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. ↑ 1 2 Ramsey, 1990.
  17. ↑ 1 2 3 Taha, 2004.
  18. ↑ 1 2 3 Taha, 2007.
  19. ↑ 1 2 Cheong - Functional Programming and 3D Games, 2005.
  20. ↑ Benton - Embedded Interpreters, 2005.
  21. ↑ Schelog, 2003.
  22. ↑ 1 2 Parsec for Haskell. Дата обращения: 2 января 2014. Архивировано 3 января 2014 года.
  23. ↑ MLRISC Library - a framework for retargetable and optimizing compiler back ends. Дата обращения: 6 февраля 2014. Архивировано из оригинала 6 декабря 2013 года.
  24. ↑ Object Language Embedding in SML with Quote/Antiquote. Дата обращения: 10 декабря 2013. Архивировано 19 июня 2016 года.
  25. ↑ Daniel de Rauglaudre. Camlp4 - Tutorial ((c) 2002 Institut National de Recherche en Informatique et Automatique). Дата обращения: 10 декабря 2013. Архивировано 24 ноября 2013 года.
  26. ↑ Martin Jambon. How to customize the syntax of OCaml, using Camlp5 ((c) 2005, 2010). Дата обращения: 10 декабря 2013. Архивировано из оригинала 26 ноября 2013 года.
  27. ↑ Дмитрий Кириллов. Ориентация на язык. Компьютерра (14 марта 2006). Дата обращения: 5 мая 2006. Архивировано 10 марта 2016 года.
  28. ↑ Игорь Тамащук. Domain Specific Language в своём приложении — это просто (22 октября 2008). Дата обращения: 24 октября 2008. Архивировано из оригинала 15 декабря 2013 года.
  29. ↑ JetBrains - DSL Development Environment. Дата обращения: 6 февраля 2014. Архивировано 7 февраля 2014 года.
  30. ↑ 1 2 Appel - A Critique of Standard ML, 1992.
  31. ↑ Paulson, 1991, 1996, Standard ML, с. 11.
  32. ↑ Martin Ward’s Homepage
  33. ↑ Elliott, Hudak - Functional reactive animation, 1997.
  34. ↑ Bawden - First-class macros have types, 2000.
  35. ↑ Sheard, S.P.Jones - Template Meta-programming for Haskell, 2002.
  36. ↑ 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.
    ».
  37. ↑ 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. Архивировано 4 июля 2014 года.
  38. ↑ Jonathan Tang. Write Yourself a Scheme in 48 Hours. Дата обращения: 2 января 2014. Архивировано 2 января 2014 года.
  39. ↑ О том, как на Хаскеле компилировать Паскаль в. Дата обращения: 2 января 2014. Архивировано 2 января 2014 года.
  40. ↑ Zhanyong Wan, Walid Taha, Paul Hudak. Event-Driven FRP. — Department of Computer Science, Yale University. Архивировано 29 октября 2013 года.
  41. ↑ PIC16C66 - PIC® Microcontrollers. Дата обращения: 10 декабря 2013. Архивировано 12 декабря 2013 года.
  42. ↑ 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. Архивировано 4 июля 2014 года.

Литература

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

  • Харольд Абельсон, Джеральд Джей Сассман, Джули Сассман. Структура и интерпретация компьютерных программ (SICP).
  • Альфред Ахо, Рави Сети, Джеффри Ульман. Компиляторы: принципы, технологии и инструменты. — Addison-Wesley Publishing Company, Издательский дом «Вильямс», 1985, 2001, 2003. — 768 с. — ISBN 5-8459-0189-8 (рус.), 0-201-10088-6 (ориг.).
  • Джон Хопкрофт, Раджив Мотвани, Джеффри Ульман. Введение в теорию автоматов, языков и вычислений. — 2-е. — Cornell University, Stanford University: Addison-Wesley Publishing Company, Издательский дом «Вильямс», 2001. — 528 с. — ISBN 5-8459-0261-4 (рус.), 0-201-44124-1 (англ.).
  • Jon Bentley. Little languages. — CACM, 1986. — Вып. 29(8). — С. 711–721.
  • Norman Ramsey. Concurrent Programming in ML. — Department of Computer Science, Princeton University, 1990.
  • Lawrence C. Paulson. ML for the Working Programmer. — 2nd edition. — Cambridge: University Press, 1991, 1996. — 478 с. — ISBN 0-521-57050-6 (hardback), 0-521-56543-X (paperback).
  • Bernard Berthomieu. OO Programming Styles in ML. — LAAS Report #2000111, Centre National De La Recherche Scientifique Laboratoire d'Analyse et d'Architecture des Systèmes, 2000.
  • Walid Taha. A Gentle Introduction to Multi-stage Programming. — Department of Computer Science, Rice University, 2004. Архивировано 4 августа 2017 года.
  • Walid Taha. A Gentle Introduction to Multi-stage Programming, Part II. — Department of Computer Science, Rice University, 2007. Архивировано 23 сентября 2015 года.
  • K. Czarnecki, J. O’Donnell, J. Striegnitz, W. Taha. DSL implementation in metaocaml, template haskell, and C++. — University of Waterloo, University of Glasgow, Research Centre Julich, Rice University, 2004. Архивировано 5 марта 2016 года.
  • Mun Hon Cheong. Functional Programming and 3D Games. — The University of New South Wales, 2005.
  • Nick Benton. Embedded Interpreters. — Journal of Functional Programming, Microsoft Research, Cambridge, 2005.
  • Walid Taha. Domain-Specific Languages. — Department of Computer Science, Rice University, 2008. Архивировано 24 октября 2013 года.
  • Norman Ramsey. Embedding an Interpreted Language Using Higher-Order Functions and Types. — Cambridge University Press, 2008.

История, анализ, критика

Ссылки