Language Oriented Programming

NOP is designed to separate the difficulties: the machine-oriented part of the code (low-level functionality) and the human-oriented (actually solving the applied problem) are developed independently of each other, which eliminates the exponential growth of the resulting complexity of developing the entire project and solves the complexity problem as a fundamental programming problem ^{[2 ]} , described by Frederick Brooks in the famous essay “ There is no Silver Bullet, ” which makes it impossible to simply improve the working tool Roumentation to increase the productivity of programmers, even an order of magnitude. Most of the other benefits directly follow from this. .

The merits of narrowing the specialization of languages ​​were discussed back in the mid -1980s ^[3] , and the merits of improving the level of languages ​​much earlier ^[4] , but DSL-oriented development did not emerge as an independent methodology until the mid -1990s .

Using DSL instead of general-purpose languages ​​significantly increases the level of code abstractness, which allows developing quickly and efficiently and creating programs that are easy to understand and maintain; and also makes it possible or significantly simplifies the solution of many problems associated with manipulating programs ( generating programs , researching a certain property of programs — correctness, efficiency, etc.) ^{[3] [1] [5] [6]} . On the other hand, the development of a new language and its effective implementation is a non-trivial problem of theoretical and applied informatics .

Among other approaches to the design of nuclear weapons programs, it stands out for its much more aggressive focus on bringing a computer closer to a person. There is an opinion among YaO researchers that in high-tech tasks, a well-designed and implemented DSL makes human-computer communication much more convenient and productive than a graphical user interface . The following popular subject-specific languages are most often cited as examples:

• AutoLisp for computer simulation ( CAD )
• Τ Ε Χ for the preparation of ( computer layout ) text documents
• Perl for text manipulation
• SQL for DBMS
• Mathematica and Maple for Symbol Computing

and etc.

The advantages of nuclear weapons are manifested even in cases where DSL is developed not for mass use, but for solving a single problem. For example, when developing the program for automatically equivalent program transition from “flat” programming in Lisp to recursive JOP (WSL was implemented in Lisp , MetaWSL was used in it, and target functionality was already implemented on it) not only allowed the total amount of code from 100 to 16 thousand lines, but at the same time it increased all the main qualitative characteristics of the code and even made it possible to solve problems that could not be solved otherwise ^[2] .

A simplified comparison of the growth of labor costs when using traditional and language-oriented approaches allows the graph ^[1] . As can be seen, nuclear weapons testing is only advisable starting from a certain threshold for the volume and complexity of the functionality of the target system.

Most YaO researchers rely on functional languages and metalanguages , which leads to a high entry threshold for developers. Martin Ward notes the possibility of implementing DSL in traditional languages, but only after its final development.

In the mainstream , embedding of the interpreter in a general-purpose language is often used (see Approach ), although this is done not only without appeal to the principles of the NLP, but often without realizing the fact of its use as such. Most often embedded: regular expression language ( PCRE interpreter), Lua , SQL , XML . A visual programming toolkit has also been developed for use in the mainstream of some of the ideas of the NPL.

Many researchers see the goal of OOP in completely blurring the boundaries between a mathematical model and its implementation on a computer and make possible the development of software by domain specialists who do not have specific programming knowledge ^{[1] [6]} :

-- проверка вхождения точки в регион:
inRegion :: Point -> Region -> Bool
p 'inRegion' r = rp
...
Thanks to the exact capture of the semantics of the subject area, even non-programmers are able to understand a significant part of the code. In an experiment commissioned by the Naval Surface Warfare Center, completely unfamiliar with Haskell people grasped the basic concepts on the fly. Some even expressed disbelief that this code was truly executable.
(In fact, despite the presence of this last sentence in the text, one of the reviewers of the first draft of this work expressed dissatisfaction with the fact that “the work is stated as reasoning about syntax and semantics at the same time, but its content mainly concerns syntax (as, for example, the definition inRegion ), and no distinction is made between mathematics and programming. "But in fact, this definition inRegion entirely semantic. Moreover, equational reasoning ^[7] ... allow to blur the line between the Mat tikoy and programming: Program can be regarded as a specification This is a special feature as expanding the use of formal methods)..

Original text

...
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 filter draft of this paper complained that “the paper claims to be interested in both syntax and semantics, but the presented details are mostly syntactic (eg, 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 speci fi ciations. This is a feature, as it enhances the application of formal methods.)

- Paul Hudak, “Modular Domain Specification of Languages ​​and Tools” ^[1]

The approach is based on the idea that a language specially designed for the task will provide obviously higher quality indicators for the code than any general purpose language ^{[1] [6]} , and that it will be more efficient to invent more complex solutions to complex industrial problems easy to understand (human-oriented ^[8] or exactly encapsulating subject knowledge ^{[2] [1]} ) language, rather than overcoming the difficulties of using an existing, even rooted in industry ^[4] .

Most researchers talk about OOP as the translation of the entire software development industry to the use of text languages ​​of the 4th and 5th generation ^[8] , but some focus on the use of visual languages ^{[9] [10]} .

The main problems of the approach are finding ways to quickly create an implementation of the invented DSL , to begin to develop a solution to the problem itself, and to ensure good DSL computing performance.

A subject-oriented language, like any programming language in general, is determined by the alphabet , grammar , semantics, and psycholinguistics , however, depending on the way DSL is implemented, the role and relationship of these levels can be blurred and / or inherited from the language of its implementation.

Different authors focus on different ways of developing subject-specific languages:

• implementation of an independent compiler (Aho - Networks - Ullman ^[11] , Knut );
• embedding an interpreter in a general-purpose language ( McCarthy , - - , Ward);
• the use of macro language tools (and often identifying them with the term “ metaprogramming ”) ( McCarthy , Leroy , Shalua - Manuri - Pagano ^[12] , Taha ^[13] );
• pure embedding ( eng. pure embedding ) ( , Haines, Hudack ^[1] , Shivers ^[14] , Bertomue ^[15] , Ramsey ^[16] ).

When using macro tools, in turn, they distinguish between template metaprogramming and multi-stage static interpretation ^{[13] [17] [18] [5]} .

The third and fourth methods have a fundamental advantage over the first two - DSL does not replace, but extends the general-purpose language ^{[14] [1] [19] [20]} , reusing all the tools of the base language, starting with the parser , due to which:

• it becomes possible to combine in a single code the capabilities of the base language, shared libraries for it, a developed subject-specific language, and even several other subject-specific languages ​​developed in a similar way, using idioms that are well-established for the base language, tricks, crossing methodologies;
• eliminates the need to implement trivial things from scratch (such as arithmetic of numbers) - just adapt the syntax;
• eliminates the need to develop a full range of development tools (optimizing translator with informative error messages, REPL , debugger, profiler, etc.). With DSL recursive embedding , code reuse reaches gigantic proportions ^[1] .

Many authors focus on the effective (without interpretation) embedding in the language of certain initially absent opportunities for adaptation to certain tasks ^{[15] [16]} , which in the future can serve as the basis for pure DSL embedding ^[21] . Considerable attention is paid to the use of continuations for the development of DSL with non-deterministic semantics ( , , , , and others).

An important subspecies of JOP is , which allows a variety of people who have no idea about computer science to efficiently solve many applied problems. The role of this application is so large that almost the most widespread programming language in the world turns out to be the means of layout spreadsheets ^[6] .

Depending on the interpretation of the term “ metaprogramming ” (MP) and the method of implementing DSL, either NPS is the quintessence of MP, or MP is one of the ways to implement NPS. The latter option is most applicable in the case of embedding DSL in a general-purpose language by means of a macro-subset of the latter ^[13] . When using visual development tools DSL ^{[9] [10],} these definitions turn out to be synonymous, because visual programming itself is the simplest form of MP. Considering MP as a self-application of nuclear weapons means:

• for embedded DSLs, the recursive application of NOPs proposed by Ward and Hudack;
• for independent DSL - promotion of the compiler ( born bootstrapping ).

To develop independent translators, lexer and parser generators are widely used based on the grammar of the target DSL by means of BNF and regular expressions :

• Lex
• Yacc
• ANTLR
• Parsec Library ^[22] for the Haskell Language

other.

When compiling an independent DSL, the target platform rarely selects machine code or even Assembler , it is more preferable (both to reduce the complexity of the DSL implementation and to increase portability) using a higher level platform:

• high-level general-purpose language;
• mid-level general-purpose language ( C , BitC , Forth )
• intermediate language or compiler framework ( C-- , MLRISC ^[23] )
• low level virtual machine ( LLVM )

The following technologies are used to embed DSL in a general-purpose language:

• Metalanguages : Lisp , ML , Haskell , Nemerle , Forth , Tcl , Rebol
• Embedding an Object Language Through Quasicitation ^[24]
• - Okamla's parametric parser ^{[25] [26]}
• Boost.Spirit library for C ++ (excluding regular grammars and )

Pure embedding does not imply any additional tools, but imposes rather strict restrictions on the choice of the base language .

When using multi-stage static interpretation, the target platform coincides with the base language ^{[13] [17] [18] [5]} .

In the framework of traditional programming (in languages ​​inherited from Algol ), the use of some ideas of the NLP makes it possible to use visual programming tools developed in the first half of the 2000s ^{[9] [10] [27] [28]} :

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

From the moment of its creation, the Lisp community has been using macro tools to adapt to the requirements of the subject area of ​​the task. This approach, in particular, was described in detail in the book Structure and interpretation of computer programs . Similar ideas have been used at times in the Forth language community. Basically, these solutions were spontaneous in nature, and often they can be classified as ad hoc solutions ^[13] .

In the second half of the 1970s, the Hindley-Milner type system was invented, which formed the basis of the ML language (the abbreviation for “ MetaLanguage ” is Russian. MetaLanguage ). Initially, ML was developed as a DSL for the system of automatic proof of theorems of , but it soon became clear that it could be a good general-purpose applied language - better than languages ​​originally designed to be general-purpose languages, because debugged on one specific complex task ^{[30] [31]} . As a result, he spawned a whole family of X-M-typed languages that gained popularity as languages ​​for developing languages ​​( metalanguages ) and are often defined as “ DSL for ” ^[1] .

In 1994, Martin Ward ^[32] gave a detailed description of the methodology ^[2] and proposed the terms “ language-oriented programming ” and “ divergent development ” (or “ development from the center to the edges ”, middle out development ), Noting that the approach in a variety of forms has been applied repeatedly before. The term “ divergent development ” emphasizes that the DSL is the middle layer in the resulting system, as opposed to the previously known and still widely used methods of “ bottom development ” ( ) ( ) and the ouside in development combining them.

Ward also suggested using NOP recursively, gradually increasing the complexity of the developed system from the bottom up; and combine YOP with rapid prototyping , developing first the simplest DSL prototype (which can be done very quickly) and the simplest solution using it, then, after testing the language, identifying flaws and clarifying requirements, refine the DSL and rewrite the solution in a new version of the language, and so on iteratively.

proposed ^[1] a pure embedding method using type - safe languages ​​(preferably lazy ones like Haskell , but maybe strict ones like ML , although in the latter case the implementation comes out a bit more cumbersome and less natural) and equational reasoning ^[7] , recursively developing a system from top to bottom and accumulating reusable code in the form of “DSL for DSL development”.

The method of pure embedding has given rise to the term “embedded subject-specific language” ( Eng. Embedded DSL, EDSL ; sometimes DSEL ) ^{[1] [8]} . A whole series of EDSL over Haskell was developed for programming in a pure functional style of real-time interactive applications (Fran, Fruit, FRP and RT-FRP, FAL, Frob, Fvision, Yampa) ^{[33] [19]} , which formed an independent paradigm - functional reactive programming (FRP). This shows that NLR is not a separate closed programming paradigm, but rather can be used as a tool in the development of new paradigms.

Around Standard ML - the basic dialect of ML - since the early 1990s, there have been disputes regarding the lack of macro tools in the language ^[30] . Critics argued that the lack of macros was a flaw, but proponents of strict typing argued that their absence was an advantage. In another ML dialect - OCaml - a compromise idea was proposed - parameterization of the syntax by allocating the parser into a custom module of the compiler, through which many EDSLs for OCaml were developed. Later, an extension for generating code at runtime appeared - . In the late 1990s, the idea of type - safe macro-tools was proposed as a tool for the effective implementation of type-safe DSL ^[34] . This idea was soon implemented in the form of extensions MetaML ^{[13] [17] [18]} for Standard ML and ^[35] for Haskell . In the first case, macro tools are considered solely as a multi-stage static interpreter; in the second, they are considered at the same time as the same approach, as well as quasi-citation known from the Lisp language, and as a template subsystem similar to that available in C ++ .

A study of the feasibility and implementation of these approaches in different languages ​​showed that C ++ is an extremely inconvenient tool for developing embedded languages ^[36] . Nevertheless, C ++ allows you to implement solutions in this direction, cultivated and debugged under the auspices of functional programming ^{[5] [37]} , which is a rare advantage for mainstream languages ^[5] .

Data from preliminary studies published in 2012 showed that independent DSL is more convenient to use, while EDSL is easier to implement ^[8] .

Advantages

The growth in complexity of any software system is fundamentally limited by the limit to which control over it can still be maintained: if the amount of information required to comprehend a component of this system exceeds the “capacity” of one person’s brain, then this component will not be fully understood. It will become extremely difficult to refine it or correct errors, and from each correction we can expect the introduction of new errors due to this incomplete knowledge.

Original text

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 fi x bugs, and each fi x 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) переносится без изменений. В случае с , реализация DSL нижнего уровня занимала всего 2-3 тысячи строк кода на Lisp , и в дальнейшем была переписана на Си всего за три человеко-дня. Другим примером служит высокая портируемость системы Τ Ε Χ . Кроме того, после создания прототипа реализации DSL дальнейшая разработка приложения может быть распараллелена — одни разработчики занимаются решением прикладной задачи, в то время как другие независимо от них реализуют DSL на разных платформах и совершенствуют эти реализации.
• Принципиальная возможность решения задач. Многие подзадачи не удавалось решить посредством классического подхода из-за превышения общей сложности решения возможностей человека по восприятию и переработке информации. Решение же на DSL оказывается не просто возможным, а очень простым и интуитивным, к тому же исключающим размножение ошибок, так как доступ к очень сложным функциям системы осуществляется через примитивы DSL.
• Получение программных систем, расширяемых их пользователями ^[6] . DSL делает программирование доступным для специалистов предметной области, не имеющих специфичных знаний в программировании , и даёт им возможность самостоятельно расширять функциональность системы, что принципиально невозможно при использовании традиционного подхода.

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

Недостатки

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

Limitations

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

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

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

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

• Харольд Абельсон, Джеральд Джей Сассман, Джули Сассман. Структура и интерпретация компьютерных программ (SICP).
• Альфред Ахо, Рави Сети, Джеффри Ульман. Компиляторы: принципы, технологии и инструменты. — Addison-Wesley Publishing Company, Издательский дом «Вильямс», 1985, 2001, 2003. — 768 с. — ISBN 5-8459-0189-8 (рус.), 0-201-10088-6 (ориг.).
• Джон Хопкрофт, Раджив Мотвани, Джеффри Ульман. Введение в теорию автоматов, языков и вычислений. - 2nd. — 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.
• 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.

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

• John Backus. Can Programming Be Liberated from the vonNeumann Style? A Functional Style and Its Algebra of Programs // ACM 0001-0782/78/0800-0613, August 1978, vol.2, #8. — IBM Research Laboratory, ACM Turing Award Lecture, 1978.
• Andrew W. Appel. A Critique of Standard ML . — Princeton University, revised version of CS-TR-364-92, 1992.
• Martin Ward . Language Oriented Programming . — Computer Science Department, Science Labs, 1994.
• Olin Shivers. A universal scripting framework, or lambda: The ultimate "little language" . — MIT AI Lab, Cambridge, 1996.
• Conal Elliott, Paul Hudak. Functional reactive animation . — International Conference on Functional Programming, 1997.
• Paul Hudak. Modular Domain Specific Languages and Tools . — IEEE Computer Society Press, Department of Computer Science, Yale University, 1998. Архивировано 17 октября 2013 года.
• A. Bawden. First-class macros have types. — 27th ACM Symposium on Principles of Programming Languages (POPL'00), 2000. — С. 133–141 .
• Steven E. Ganz, Amr Sabry, Walid Taha . Macros as Multi-Stage Computations: Type-Safe, Generative, Binding Macros in MacroML . — International Conference on Functional Programming, ACM Press, 2001. Архивировано 23 сентября 2015 года.
• Tim Sheard, Simon Peyton Jones . Template Meta-programming for Haskell . — ACM 1-58113-415-0/01/0009, 2002.
• Marjan Mernik. Formal and Practical Aspects of Domain-Specific Languages . — IGI Global, 2012. — ISBN 978-1-4666-2092-6 .

• Dorai Sitaram. Programming in Schelog (неопр.) (2003).
• Compilers and interpreters implemented in Haskell (неопр.) .