8.2. Применение мини-языков. 8. Мини-языки: поиск выразительной нотации. Часть II. Проектирование. Искусство программирования для Unix.

Искусство программирования для Unix.

8.2. Применение мини-языков.

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

8.2.1. Учебный пример: sng.

В главе 6 рассматривалась утилита sng(1), преобразовывающая PNG-файл в редактируемую полностью текстовую форму. Формат файлов данных SNG заслуживает повторного рассмотрения здесь для контраста, поскольку он не вполне является узкоспециальным мини-языком. Он описывает расположение данных, но не связывает с ними какую-либо предполагаемую последовательность действий.

Однако SNG действительно имеет одну общую важную характеристику с узкоспециальными мини-языками, которую не поддерживают структурированные двоичные форматы данных, подобные PNG, — прозрачность. Структурированные файлы данных позволяют без использования мини-языка взаимодействовать средствам редактирования, преобразования и создания, которые не имеют информации о конструкторских "предположениях" друг друга. В случае SNG добавляется то, что данный формат как узкоспециальный мини-язык, предназначен для простого просмотра и редактирования с помощью универсальных средств.

8.2.2. Учебный пример: регулярные выражения.

Одним из видов спецификации, который периодически появляется в инструментах Unix и языках сценариев, является регулярное выражение (regular expression, или regexp для краткости). Здесь регулярные выражения рассматриваются как декларативный мини-язык для описания текстовых шаблонов. Часто регулярные выражения встраиваются в другие мини-языки. Регулярные выражения настолько распространены, что их едва ли можно считать мини-языком, однако они заменяют то, что в противном случае представляло было собой огромные объемы кода, реализующего различные (и несовместимые) возможности поиска.

В данном введении не рассматриваются такие подробности, как POSIX-расширения, обратные ссылки и особенности интернационализации. Более подробное изложение способа их применения представлено в книге "Mastering Regular Expressions" [22].

Регулярные выражения описывают шаблоны, которые могут либо совпадать, либо не совпадать со строками. Простейшим средством для работы с регулярными выражениями является утилита grep(1), фильтр, который переправляет со стандартного ввода на стандартный вывод каждую строку, соответствующую указанному регулярному выражению. Форма записи регулярных выражений кратко представлена в таблице 8.1.

Таблица 8.1. Примеры регулярных выражений.

Регулярное выражение	Соответствующая строка
"x.y"	x, за которым следует любой символ с последующим у
"x\.y"	х, за которым следует точка с последующим у
"xz?y"	х, за которым следует не более одного символа z с последующим у, т.е. "xy" или "xzy", но не "xz" или "xdy"
"xz*y"	х, за которым следует любое количество символов z, за которыми следует y, т.е. "xy" или "xzy" или "xzzzy", но не "xz" или "xdy"
"xz+y"	x, за которым следует один или несколько экземпляров символа z, за которыми следует у, т.е. " xzy" или " xzzy", но не " xy", " xz" или " xdy"
"s[xyz]t"	s, за которым следует любой из символов х, у или z, за которым следует t, т.е. " sxt", " syt" или " szt", но не " st" или " sat"
"a[x0-9]b"	а, за которым следует либо х, либо символ в диапазоне 0-9, за которым следует b, то есть, " axb", " a0b" или " а4b", но не " ab" или " aab"
"s[^xyz] t"	s, за которым следует любой символ, кроме х, у или z, за которым следует t, т.е. " sdt" или " set", но не "sxt", " syt" или " szt"
"s[^x0-9]t"	s, за которым следует любой символ, кроме x или символа в диапазоне 0-9, за которым следует t, т.е. " slt" или " smt", но не " sxt", " s0t" или " s4t"
"^x”	x в начале строки, т.е. " xzy" или " xzzy", но не " yzy" или " уху"
"x$"	х в конце строки, т.е. " yzx" или " yx", но не " yxz" или " zxy"

Существует большое количество второстепенных вариантов записи регулярных выражений.

1. Выражения-маски. Ограниченный набор соглашений по применению символов-шаблонов (wildcard), использовавшийся в ранних оболочках Unix для сопоставления имен файлов. Существует всего 3 символа-шаблона: * — соответствует любой последовательности символов (как .* в других вариантах); ? — соответствует любому единичному символу (как . в других вариантах); [...] — соответствует классу символов как в других вариантах. В некоторых оболочках (csh, bash, zsh) позднее был добавлен шаблон {} для выбора подстроки. Таким образом, выражение x{a,b}c соответствует строкам xac или xbc, но не xc. В некоторых оболочках выражения-маски получили дальнейшее развитие в направлении расширения регулярных выражений.

2. Базовые регулярные выражения. Форма записи, принятая в исходной утилите grep(1) для извлечения из файла строк, соответствующих заданному регулярному выражению. Выражения этого типа также применяются в строковом редакторе ed(1) и потоковом редакторе sed(1). Профессионалы старой школы Unix считают данное выражение основной, или "унифицированной", разновидностью регулярных выражений. Пользователи, впервые столкнувшиеся с более современными инструментами, склонны использовать расширенную форму, которая описана ниже.

3. Расширенные регулярные выражения. Запись, принятая в расширенной версии grep, egrep(1) для извлечения из файла строк, соответствующих заданному регулярному выражению. Регулярные выражения в Lex и редакторе Emacs весьма близки к egrep-разновидности.

4. Регулярные выражения языка Perl. Форма записи, принятая в regexp-функциях языков Perl и Python. Выражения этого типа являются более мощными по сравнению с egrep-вариантом.

После рассмотрения основных примеров в таблице 8.2 приведена сводка стандартных шаблонов для регулярных выражений. Следует отметить, что в таблицу не включен вариант выражений-масок, поэтому запись "для всех" означает только 3 типа: базовый, расширенный/Еmасs и Perl/Python[79].

Таблица 8.2. Введение в операции с регулярными выражениями.

Символ-шаблон	Поддерживается	Соответствующая строка
\	во всех	Начало escape-последовательности. Определяет, следует ли интерпретировать последующий знак как шаблон. Последующие буквы или цифры интерпретируются различными способами в зависимости от программы
.	во всех	Любой символ
^	во всех	Начало строки
$	во всех	Конец строки
[...]	во всех	Любой из символов, указанных в скобках
[^...]	во всех	Любые символы, кроме указанных в скобках
*	во всех	Любое количество экземпляров предыдущего элемента
?	egrep/Emacs, Perl/Python	Ни одного или один экземпляр предыдущего элемента
+	egrep/Emacs, Perl/Python	Один или несколько экземпляров предыдущего элемента
{n}	egrep, Perl/Python; как \{n\} в Emacs	В точности n повторений предыдущего элемента. Не поддерживается некоторыми старыми regexp-средствами
{n,}	egrep, Perl/Python; как \{n,\} в Emacs	n или более повторений предыдущего элемента. Не поддерживается некоторыми старыми regexp-средствами
{m,n}	egrep, Perl/Python; как \{m,n\} в Emacs	Минимум m и максимум n повторений предыдущего элемента. Не поддерживается некоторыми старыми regexp-средствами
\|	egrep, Perl/Python; как \\| в Emacs	Элемент слева или справа. Обычно используется с некоторой формой группирующих разделителей
(...)	Perl/Python; как $...$ в более старых версиях	Интерпретировать данный шаблон как группу (в более новых regexp-функциях, например в языках Perl и Python). Более старые средства, такие как regexp-функции в Emacs и в утилите grep требуют записи $...$

В новых языках с поддержкой регулярных выражений установилась практика Perl/Python-варианта. Он является более прозрачным, чем остальные, особенно потому, что обратная косая черта перед не алфавитно-цифровым символом всегда означает, что данный символ трактуется буквально, что значительно устраняет путаницу при ссылке на элементы регулярных выражений.

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

8.2.3. Учебный пример: Glade.

Glade представляет собой средство разработки интерфейсов для библиотеки Х-инструментария[80] GTK с открытым исходным кодом. Glade позволяет разрабатывать GUI-интерфейс путем интерактивного выбора, размещения и модификации элементов управления на панели интерфейса. GUI-редактор создает XML-файл, описывающий проектируемый интерфейс. Полученный файл, в свою очередь, можно передать одному из нескольких генераторов кода, которые непосредственно создают С, С++, Python- или Perl-код для интерфейса. Сгенерированный код затем вызывает создаваемые разработчиком функции, определяющие поведение интерфейса.

XML-формат Glade для описания GUI-интерфейсов является хорошим примером простого узкоспециального мини-языка. В примере 8.1 показан Glade-формат для GUI-интерфейса "Hello, world!".

Адекватная спецификация в Glade-формате предполагает набор действий, предпринимаемых GUI-интерфейсом в ответ на действия пользователя. GUI-интерфейс Glade интерпретирует данные спецификации как структурированные файлы данных. С другой стороны, генераторы кода Glade используют их для написания программ, реализующих GUI. Для некоторых языков (включая Python) существуют библиотеки времени выполнения, которые позволяют пропустить этап генерирования кода и просто создавать GUI непосредственно во время обработки XML-спецификации (интерпретируя Glade-разметку вместо того, чтобы компилировать ее). Таким образом, разработчик получает выбор: эффективное использование пространства ценой скорости запуска или наоборот.

Программисту, освоившему подробности XML-формата, разметка Glade представляется довольно простым языком. Она решает только две задачи: объявляет иерархии GUI-элементов и связывает свойства с элементами управления. Чтобы прочесть спецификацию, представленную в примере, разработчику фактически не требуется досконально разбираться в работе glade. Действительно, имея опыт программирования с помощью GUI-инструментариев и читая данную спецификацию, можно сразу довольно наглядно представить себе интерфейс, создаваемый glade на ее основе. (Для тех, кто не имеет такого опыта, можно отметить, что данная спецификация позволяет получить однокнопочный элемент управления в окне).

Пример 8.1. Glade-спецификация "Hello, world!".

<?xml version="1.0"?>

<GTK-Interface>

<class>GtkWindow</class>

<name>HelloWindow</name>

<border_width>5</border_width>

<name>destroy</name>

</Signal>

<title>Hello</title>

<type>GTK_WINDOW_TOPLEVEL</type>

<allow_shrink>True</allow_shrink>

<allow_grow>True</allow_grow>

<auto_shrink>False</auto_shrink>

<class>GtkButton</class>

<name>Hello World</name>

<can_focus>True</can_focus>

<name>clicked</name>

<handler>gtk_widget_destroy</handler>

</Signal>

<label>Hello World</label>

</widget>

</GTK-Interface>

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

Основой функциональный тест для подобного мини-языка прост: возможно ли разобраться в данном языке, не изучая руководство? Для значительного количества случаев использования Glade это так. Например, зная константы C-уровня, которые в GTK используются для описания параметров позиционирования окна, можно распознать константу GTK_WIN_POS_NONE как одну из них и немедленно получить возможность изменить параметры позиционирования, связанные с данным GUI-интерфейсом.

Преимущества использования Glade должны быть очевидны. Данная программа специализируется на создании кода, что освобождает разработчика от необходимости его собственной специализации. То есть Glade принимает на себя одну рутинную задачу, которую в противном случае придется решать вручную. Кроме того, разработчик избавляется от одного из источников ошибок, неизбежных при ручном кодировании.

Более подробная информация, включая исходный код, документацию и ссылки на примеры приложений, доступны на странице проекта Glade <http://glade.gnome.org/>. Программа Glade перенесена на платформу Microsoft Windows.

8.2.4. Учебный пример: m4.

Макропроцессор m4(1) интерпретирует декларативный мини-язык для описания трансформаций текста. Программа m4 представляет собой набор макросов, который определяет способы преобразования одних текстовых строк в другие. В результате применения описаний к входному тексту с командами m4 происходит макрорасширение и на выходе создается текст. (Препроцессор С предоставляет аналогичные службы для компиляторов С, хотя и в несколько отличающемся стиле.).

В примере 8.2 показана макрокоманда m4, которая заставляет утилиту m4 преобразовывать каждое вхождение строки "OS" в тесте ввода в строку "operating system" на выводе. Данный пример тривиален. m4 поддерживает макросы с аргументами, которые можно использовать для более сложных операций, чем просто преобразование одной фиксированной строки в другую. Ввод info m4 в командную строку оболочки позволит получить справочную документацию по данному языку.

Пример 8.2. Макрокоманда m4.

Define(`OS', `operating system').

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

Макропроцессор m4 обычно используется как препроцессор для мини-языков, которые испытывают недостаток встроенного понятия именованных процедур или встроенной функции включения файлов. Это простой путь для расширения синтаксиса базового языка, так чтобы комбинация с m4 поддерживала обе эти функции.

Одним из широко известных способов применения m4 является очистка (или, по крайней мере, эффективное сокрытие) другой конструкции мини-языка, который ранее в данной главе был назван плохим примером. В настоящее время большинство системных администраторов генерируют конфигурационные файлы sendmail.cf с помощью пакета макрокоманд m4, который поставляется с дистрибутивом sendmail. Макросы начинают с имен функций (или пар имя/значение) и генерируют соответствующие (гораздо более уродливые) строки на языке конфигурации программы sendmail.

Однако m4 следует использовать осмотрительно. Опыт Unix научил разработчиков мини-языков остерегаться макрорасширения. Причины этого описываются далее в настоящей главе.

8.2.5. Учебный пример: XSLT.

Язык XSLT, подобно макросам m4, является языком для описания трансформаций текстового потока. Однако он делает гораздо больше, чем просто подмену макрокоманд. Он описывает трансформации XML-данных, включая создание запросов и отчетов. XSLT — язык для написания таблиц стилей XML. В целях практического применения рекомендуется изучить описание обработки XML-документов в главе 18. XSLT описан стандартом Консорциума World Wide Web и имеет несколько реализаций с открытым исходным кодом.

XSLT и макросы m4 являются как исключительно декларативными языками, так и языками Тьюринга, но XSLT поддерживает только рекурсии и не поддерживает циклы. Он весьма сложен, несомненно, наиболее трудный для освоения язык из всех упомянутых в учебных примерах данной главы, а возможно, и самый трудный язык из упомянутых в этой книге[81].

Несмотря на сложность, XSLT действительно является мини-языком. Он обладает важными (хотя и не всеми) характеристиками своего класса:

• ограниченная онтология типов, в частности, без каких-либо аналогов структур записи или массивов;

• ограниченный интерфейс для связи с внешним миром; XSLT-процессоры предназначены для фильтрации стандартного ввода на стандартный вывод, с ограниченными возможностями считывать и записывать файлы; они не способны открывать сокеты или запускать подкоманды.

Программа в примере 8.3, трансформирует XML-документ так, что каждый атрибут каждого элемента трансформируется в новую пару тегов, непосредственно заключенную внутри элемента. Значение атрибута представлено как содержимое пары тегов.

Краткий обзор XSLT приведен здесь отчасти для иллюстрации того факта, что понятие "декларативности" не подразумевает "простоту" или "слабость", и главным образом ввиду того, что необходимость работы с XML-документами рано или поздно приводит к проблеме, каковой является XSLT.

Книга "XSLT: Mastering XML Transformations" [84] является хорошим введением в изучение данного языка. Краткие учебные материалы с примерами доступны в Web[82].

Пример 8.3. XSLT-программа.

<?xml version="1.0"?>

<xsl:stylesheet.

xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:output method="xml"/>

<xsl:template match="*">

<xsl:element name="{name()}">

<xsl:for-each select="@*">

<xsl:element name="{name()}">

<xsl:value-of select="."/>

</xsl:element>

</xsl:for-each>

<xsl:apply-templates select="*|text()"/>

</xsl:element>

</xsl:template>

</xsl:stylesheet>

8.2.6. Учебный пример: инструментарий Documenter's Workbench.

Программа troff(1), средство форматирования текстов, была, как отмечалось в главе 2, первоначальным главным приложением операционной системы Unix. Программа troff является наиболее важной в наборе форматирующих средств (получивших коллективное название DWB, (Documenter's Workbench — автоматизированное рабочее место документатора), каждое из которых является отдельным узкоспециальным мини-языком. Большинство из них являются либо препроцессорами, либо постпроцессорами для troff-разметки. В Unix-системах с открытыми исходными кодами используется расширенная реализация DWB (которая называется groff(1)), созданная Фондом свободного программного обеспечения.

Подробнее программа troff рассматривается в главе 18. Здесь достаточно отметить, что она представляет собой хороший пример императивного мини-языка, граничащего с полностью проработанным интерпретатором (в troff поддерживаются условные операции и рекурсия, но нет циклов; troff — отчасти язык Тьюринга).

Постпроцессоры ("драйверы" в терминологии DWB) обычно невидимы для пользователей troff. Первоначально созданные troff-коды для отдельных наборных машин были доступны группе разработки Unix в 1970 году. Позднее они были улучшены до аппаратно-независимого мини-языка для размещения текста и простой графики на страницах. Постпроцессоры преобразовывают данный язык (получивший название "ditroff от device-independent troff — аппаратно-независимый troff) в некоторые данные, которые фактически могут принимать современные графические принтеры — наиболее важным из них (и современным стандартом) является PostScript.

Препроцессоры более интересны, поскольку они фактически расширяют возможности языка troff. Существует 3 распространенных препроцессора: tbl(1) для создания таблиц, eqn(1) для текстового представления математических уравнений и pic(1) для создания диаграмм. Реже используются, но до сих пор сохранились gm(1) для графики, refer(1) и bib(1) для форматирования библиографий. Эквиваленты данных программ с открытыми исходными кодами поставляются с пакетом groff. Препроцессор grap(1) предоставлял довольно гибкое средство для построения графиков; отдельно от groff существует его реализация с открытым исходным кодом.

Некоторые другие препроцессоры не имеют реализации с открытым исходным кодом и в настоящее время широко не используются. Наиболее известным из них была программа ideal(1) для форматирования графики. Более новый член данного семейства, chem(1) отображает формулы химических структур; программа доступна в репозитории netlib Bell Labs[83].

Каждый из описанных препроцессоров представляет собой небольшую программу, которая принимает мини-язык и компилирует его в troff-запросы. Каждый препроцессор распознает разметку, которую необходимо интерпретировать, путем поиска уникального начального и конечного запроса, а любую разметку за пределами таких запросов оставляет неизменной (программа tbl ищет строки TS/.TE, pic — .PS/.РЕ и т.п.). Таким образом, большинство препроцессоров обычно могут работать в любом порядке, не влияя на другую разметку. Существует несколько исключений: в частности, программы chem и grap используют команды программы pic, и поэтому в конвейерах она должна следовать после них.

Cat thesis.ms | chem | tbl | refer | grap | pic | eqn \

| groff -Tps >thesis.ps.

Выше приведен подробный пример конвейера DWB-обработки для гипотетических тезисов, включающих в себя химические формулы, математические уравнения, таблицы, библиографию, графики и диаграммы. (Команда cat(1) просто копирует свой ввод или содержимое указанного файла на свой вывод; здесь она используется для подчеркивания порядка операций.) На практике современные реализации troff часто поддерживают параметры командной строки, которые способны вызвать, по крайней мере, такие программы, как tbl(1), eqn(1) и pic(1), а поэтому писать такие сложные конвейеры не обязательно. Но даже если бы это понадобилось, такие инструкции для сборки обычно создаются один раз и сохраняются в make-файле или в shell-сценарии для повторного использования.

Разметка документов средствами Documenter's Workbench несколько устарела, однако диапазон проблем, которые решаются препроцессорами, является некоторым показателем мощности модели мини-языков — было бы чрезвычайно трудно встроить эквивалентные знания в текстовые процессоры класса WYSIWYG. Существует несколько областей, где современные инструментальные связки и способы разметки документов на основе XML, в 2003 году лишь приближаются к возможностям, которыми инструментарий DWB обладал в 1979 году. Эти вопросы подробнее освещаются в главе 18.

Конструктивные идеи, которые дали инструментарию DWB такую мощь, в настоящее время должны быть очевидны. Все инструменты совместно используют общее представление документов в виде текстовых потоков, а система форматирования разбита на независимые компоненты, которые можно отлаживать и совершенствовать по отдельности. Структура конвейеров поддерживает интеграцию с новыми, экспериментальными препроцессорами и постпроцессорами без нарушения работы старых. DWB — модульная и расширяемая конструкция.

Структура инструментария Documenter's Workbench в целом преподносит некоторые уроки того, как связывать несколько специальных языков во взаимодействующую систему. Один препроцессор может быть надстройкой доя другого. Действительно, инструментальные средства DWB были ранними примерами, демонстрирующими мощность каналов, фильтров и мини-языков, которые в дальнейшем во многом повлияли на конструкцию Unix. Конструкции отдельных препроцессоров способны предоставить еще больше примеров того, как выглядит конструкция эффективного мини-языка.

Один из этих уроков отрицательный. Иногда пользователи, пишущие описание в мини-языке, допускают некорректные действия с низкоуровневой troff-разметкой, вставленной вручную. Это может повлечь за собой последствия и ошибки, которые трудно диагностировать, поскольку данные, сгенерированные troff и выходящие из конвейера, не видны, а если бы были видны, то были бы нечитаемыми. Такие ошибки аналогичны ошибкам, которые возникают в коде, когда C-код смешан с фрагментами ассемблера. Было бы лучше, если бы уровни языков были разделены более основательно, если бы это было возможно. Разработчикам мини-языков следует учесть эти проблемы.

Все языки препроцессоров (кроме самой troff-разметки) имеют сравнительно четкий, shell-подобный синтаксис, которые соответствует многим описанным в главе 5 соглашениям о конструкции форматов файлов данных. Существует несколько затруднительных исключений. Особенно выделяется среди них программа tbl(1), по умолчанию использующая символ табуляции как разделитель полей между столбцами таблицы, дублирующая неприятные недоработки в конструкции make(1) и вызывающая досадные ошибки, когда редакторы или другие средства невидимо изменяют состав разделителей.

Хотя troff сам по себе представляет собой специализированный императивный мини-язык, одной из идей, которая "проходит" как минимум через 3 мини-языка в DWB, является декларативная семантика: компоновка документа на основе ограничивающих условий. Данная идея также характерна для современных GUI-инструментариев. Вместо того чтобы указывать координаты пикселей для графических объектов, единственное, что действительно требуется сделать — это объявить пространственные взаимозависимости между ними ("элемент управления А расположен выше элемента В, который находится слева от элемента С"), а затем заставить программное обеспечение вычислить наилучшее расположение элементов А, В и С, соответствующее заданным ограничивающим условиям.

В программе pic(1) данный подход используется для компоновки элементов диаграмм. Диаграмма классификации языков на рис. 8.1 была создана на основе приведенного в примере 8.4[84] исходного pic-кода, обработанного с помощью команды pic2graph, которая рассматривалась в одном из учебных примеров главы 7.

Это весьма типичная для Unix конструкция мини-языка, и как таковая она имеет несколько интересных моментов даже на уровне синтаксиса. Следует отметить ее сходство с shell-программой: комментарии начинаются с символа #, а синтаксис, очевидно, организован на основе лексем и имеет простейшее возможное соглашение для строк. Разработчик pic(1) знал, что Unix-программисты ожидают подобный этому синтаксис мини-языков, если не существует значительной и специфической причины не делать этого. В данном случае в полной мере выполняется правило наименьшей неожиданности.

Пример 8.4. pic-код для схемы классификации языков.

#Minilanguage taxonomy (классификация мини-языков).

# Base ellipses (основные эллипсы).

Define smallellipse {ellipse width 3.0 height 1.5}.

M: ellipse width 3.0 height 1.8 fill 0.2.

Line from M.n to M.s dashed.

D: smallellipse() with .e at M.w + (0.8, 0).

Line from D.n to D.s dashed.

I: smallellipse() with .w at M.e - (0.8, 0).

# Captions (подписи).

"" "Data formats" at D.s.

"" "Minilanguages" at M.s.

"" "interpreters" at I.s.

# Heads (заголовки).

Arrow from D.w + (0.4, 0.8) to D.e + (-0.4, 0.8).

"flat to structured" "" at last arrow.с.

Arrow from M.w + (0.4, 1.0) to M.e + (-0.4, 1.0).

"declarative to imperative" "" at last arrow.с.

Arrow from I.w + (0.4, 0.8) to I.e + (-0.4, 0.8).

"less to more general" "" at last arrow.с.

# The arrow of loopiness (стрелка развития циклов).

Arrow from D.w + (0, 1.2) to I.e + (0, 1.2).

"increasing loopiness" "" at last arrow.с.

# Flat data files (плоские файлы данных).

"/etc/passwd" ".newsrc" at 0.5 between D.c and D.w.

# Structured data files (структурированные файлы данных).

"SNG" at 0.5 between D.c and M.w.

# Datafile/minilanguage borderline cases (пограничные случаи файлы данных/мини-язык).

"regexps" "Glade" at 0.5 between M.w and D.e.

# Declarative minilanguages (декларативные мини-языки).

"m4" "Yacc" "Lex" "make" "XSLT" "pic" "tbl" "eqn" \

at 0.5 between M.с and D.e.

# Imperative minilanguages (императивные мини-языки).

"fetchmail" "awk" "troff" "Postscript" at 0.5 between M.c and I.w.

# Minilanguage/interpreter borderline cases (пограничные случаи.

мини-язык/интерпретатор).

"dc" "bc" at 0.5 between I.w and M.e.

# Interpreters (интерпретаторы).

"Emacs Lisp" "JavaScript" at 0.25 between M.e and I.e.

"sh" "tcl" at 0.55 between M.e and I.e.

"Perl" "Python" "Java" at 0.8 between M.e and I.e.

Вероятно, больших усилий не потребуется, чтобы понять, что первая строка кода представляет собой определение макрокоманды. В последующих ссылках на smallellipse() инкапсулирован повторяющийся элемент диаграммы. Назначение команды arrow также очевидно.

Используя все это как подсказку и глядя на реальную диаграмму, несложно выяснить значение остальных элементов синтаксиса (позиционных ориентиров, таких как М.s, и конструкций, подобных last arrow или at 0.25 between M.e and I.e, или добавление смещения вектора). Как и Glade-разметка, а также m4-код, пример, подобный данному, может прояснить многое в языке без каких-либо ссылок на руководства (к сожалению, свойство компактности для troff(1)-разметки не характерно).

Пример программы pic(1) отражает общую для мини-языков идею конструкции, которая также отражается в Glade — использование интерпретатора мини-языка для инкапсуляции некоторой формы логических расчетов на основе ограничивающих условий и превращения ее в действия. Программу pic(1), в сущности, можно было бы рассматривать скорее как императивный, а не декларативный язык; в ней имеются элементы обоих видов, и дискуссия быстро переросла бы теологическую.

Комбинация макросов с компоновкой на основе ограничивающих условий позволяет программе pic(1) выражать структуру диаграмм таким способом, который недоступен для более современных векторных разметок, таких как SVG. Следовательно, благоприятно, то, что одним из следствий конструкции Documenter's Workbench является то, что она относительно упрощает использование программы pic(1) за пределами среды DWB. Сценарий pic2graph, использованный в качестве учебного примера в главе 7, был специально создан для достижения этой цели с помощью модернизированных PostScript-возможностей groff(1) как промежуточный этап на пути к современному растровому формату.

Более четким решением является утилита pic2plot(1), распространяемая с пакетом GNU plotutils, в которой использована внутренняя модульность кода GNU pic(1). Код был разделен на клиентскую часть, выполняющую синтаксический анализ, и серверную часть, генерирующую troff-разметку. Обе части взаимодействовали посредством уровня чертежных примитивов. Поскольку данная конструкция подчинялась правилу модульности, программисты pic2plot(1) имели возможность отделить этап синтаксического анализа GNU pic и реконструировать чертежные примитивы с помощью современной библиотеки для построения графиков. Однако их решение имеет один недостаток. Текст на выходе генерируется со встроенными в pic2plot шрифтами, которые не соответствуют шрифтам troff.

8.2.7. Учебный пример: синтаксис конфигурационного файла fetchmail.

Рассмотрим пример 8.5.

Конфигурационный файл может рассматриваться как императивный мини-язык. Существует предполагаемый поток выполнения: повторяющаяся, циклическая обработка списка команд опроса ("засыпающая" на время в конце каждого цикла) и последовательный сбор почты с каждого из указанных узлов для каждого пользователя, связанного с определенными узлами. Данный язык далек от универсальных языков. Все, что он способен делать, — создавать последовательность команд опроса серверов.

Как и в случае с программой pic(1), данный мини-язык можно рассматривать как объявления либо как слабый императивный язык и бесконечно спорить об отличиях. С одной стороны, в нем нет ни условных операторов, ни рекурсии, ни циклов. Фактически он вообще не имеет явных управляющих структур. С другой стороны, он описывает скорее действия, чем зависимости, что отличает его от исключительно декларативного синтаксиса, подобного GUI-описаниям Glade.

Пример 8.5. Синтетический код fetchmailrc.

#Опрашивать данный узел первым в цикле.

Poll pop.provider.net proto pop3.

user "jsmith" with pass "secret1" is "smith" here.

user jones with pass "secret2" is "jjones" here with options keep.

# Опрашивать данный узел вторым

Poll billywig.hogwarts.com with proto imap:

user harry_potter with pass "floo" is harry_potter here.

# Опрашивать данный узел третьим в цикле.

# Пароль будет взят из файла ~/.netrc.

Poll mailhost.net with proto imap:

user esr is esr here.

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

Примечательной особенностью синтаксиса .fetchmailrc является использование необязательных ключевых слов, которые поддерживаются просто для того, чтобы язык спецификаций более походил на английский язык. Ключевые слова "with" и однократное употребление слова "options" в примере фактически не являются обязательными, но позволяют упростить описания для чтения.

Традиционно подобный синтаксис называется синтаксическим сахаром (syntactic sugar). Данному термину сопутствует известное высказывание о том, что "синтаксический сахар вызывает рак двоеточий"[85]. Действительно, чтобы синтаксический сахар не создавал трудностей больше, чем может решить проблем, его необходимо использовать умеренно.

В главе 9 показано, как создание программ, управляемых данными, способствует изящному решению проблемы редактирования конфигурационных файлов fetchmail с помощью графического интерфейса.

8.2.8. Учебный пример: awk.

Мини-язык awk является инструментальным средством Unix старой школы, прежде широко используемым в shell-сценариях. Как и m4, утилита awk предназначена для написания небольших, но выразительных программ для преобразования текстового ввода в текстовый вывод. Версии утилиты поставляются со всеми Unix-системами. Некоторые из них реализованы с открытым исходным кодом. Команда info gawk в командной строке Unix весьма вероятно позволит получить справочную документацию по программе.

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

Каждое действие кодируется на языке, подобном подмножеству языка С, с переменными, условными операторами, циклами и онтологией типов, включая целые числа, строки и (в отличие от С) словари[86].

Язык действий awk является языком Тьюринга и позволяет считывать и записывать файлы. В некоторых версиях он также позволяет открывать и использовать сетевые сокеты. Однако awk главным образом используется как генератор отчетов, особенно для интерпретации и предварительной обработки табличных данных. Он редко используется автономно, но часто встраивается в сценарии. В главе 9, в учебном примере по созданию HTML-документа имеется пример awk-программы.

Учебный пример awk приведен в этой книге, чтобы подчеркнуть, что данный язык не является моделью для подражания. Фактически с 1990 года awk почти совершенно вышел из употребления. На смену ему пришли языки сценариев новой школы, особенно Perl, который явно предназначался для того, чтобы полностью вытеснить awk. Причины достойны внимания, поскольку они поучительны для разработчиков мини-языков.

Язык awk первоначально разрабатывался как небольшой, выразительный язык специального назначения для создания отчетов. К сожалению, его соотношение сложность-мощность оказалось неудачным. Язык действий некомпактен, а шаблонно-управляемая структура, внутри которой он содержится, не позволяет применять его широко. Данный язык унаследовал худшие черты обоих миров. Кроме того, языки сценариев новой школы могут решать все задачи, решаемые awk. Эквивалентные программы, написанные на этих языках, обычно также, если не лучше, читабельны.

Язык awk вышел из употребления также вследствие того, что более современные оболочки обладают средствами вычислений с плавающей точкой, ассоциативными массивами, поддержкой регулярных выражений и средствами обработки подстрок, поэтому эквивалентные небольшим awk-сценариям программы могут быть реализованы без издержек создания процесса. Дэвид Корн.

В течение нескольких лет после выхода языка Perl в 1987 году, awk оставался конкурентоспособным просто потому, что имел меньшую и более быструю реализацию. Однако по мере того как стоимость вычислительных циклов и памяти падала, экономические причины для привлекательности языка специального назначения, который сравнительно экономно использовал оба ресурса, теряли свою силу. Программисты для реализации awk-подобных функций все более отдавали предпочтение Perl или (позднее) языку Python, вместо того, чтобы удерживать в памяти два различных языка сценария[87]. К 2000 году awk стал для большинства Unix-хакеров старой школы немногим больше, чем воспоминание, но не самое дорогое.

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

8.2.9. Учебный пример: PostScript.

PostScript — мини-язык, специализацией которого является описание форматированного текста и графики для графических устройств. Данный язык был импортирован в Unix. Он основывался на разработке легендарного центра "Xerox Palo Alto Research Center", созданной во время появления первых лазерных принтеров. В течение нескольких лет после выхода первой коммерческой версии в 1984 году, PostScript оставался доступным только как частный продукт Adobe, Inc. и главным образом ассоциировался с компьютерами Apple. PostScript был клонирован на условиях лицензионного соглашения, очень близкого к лицензиям на открытые исходные коды, и с тех пор стал стандартом де-факто для управления принтерами в операционной системе Unix. Версия с полностью открытым исходным кодом поставляется с большинством современных Unix-систем[88]. Также доступно подробное техническое введение в PostScript[89].

PostScript обладает некоторым функциональным сходством с разметкой troff. Оба языка предназначены для управления принтерами и другими графическими устройствами, и оба обычно генерируются программами или пакетами макрокоманд, а не вручную. Однако тогда как запросы troff являются быстро созданным набором кодов для управления форматом, PostScript был спроектирован снизу вверх как язык и является гораздо более выразительным и мощным. Главное из того, что делает PostScript, — это алгоритмические описания изображений, имеющие гораздо меньшие размеры, чем представленные ими растровые изображения, и поэтому требующие меньше пространства для хранения и меньшей полосы пропускания при передаче.

PostScript является явным языком Тьюринга, поддерживающим условные операции, циклы, рекурсию и именованные процедуры. Онтология типов включает в себя целые и действительные числа, строки и массивы (каждый элемент массива может иметь любой тип), но не имеет эквивалента структур. Технически PostScript является языком, работающим со стеками. Аргументы примитивных процедур (операторов) PostScript обычно извлекаются из магазинного стека аргументов, а результат (или результаты) возвращаются обратно в стек.

Существует около 40 базовых операторов (при том, что общее их приблизительное количество — 400). Большую часть работы выполняет оператор show, который отображает строку на странице. Другие операторы устанавливают текущий шрифт, изменяют цвет, рисуют линии, дуги или кривые Безье, окрашивают закрытые области, устанавливают области отсечения, а также выполняют другие операции. Подразумевается, что интерпретатор PostScript транслирует данные команды в растровые изображения для передачи на экран или печатный носитель.

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

Исторически PostScript-интерпретация на основе стеков имеет сходство с языком FORTH, который первоначально предназначался для управления приводами телескопов в реальном времени и имел кратковременную популярность в 80-х годах прошлого века. Языки обработки стеков отличаются превосходной поддержкой чрезвычайно плотного, экономичного кода и печально известны тем, что их трудно читать. Для PostScript характерны обе эти особенности.

PostScript часто реализуется в виде встроенного в принтер программного обеспечения. Ghostscript, реализация PostScript с открытым исходным кодом транслирует PostScript в различные графические форматы и (более слабые) языки управления принтерами. Большая часть остального программного обеспечения обрабатывает PostScript как окончательный формат вывода, который предназначен для передачи PostScript-совместимому графическому устройству, а не для редактирования или просмотра.

PostScript (в оригинальном или упрощенном варианте EPSF с объявленным вокруг него обрамлением, позволяющим встраивать его в другие графические форматы) является очень хорошо спроектированным примером специализированного языка управления и, как модель, заслуживает внимательного изучения. Он является компонентом других стандартов, например, PDF (Portable Document Format — формат для переносимых документов).

8.2.10. Учебный пример: утилиты bc и dc.

Впервые утилиты bc(1) и dc(1) рассматривались в главе 7 как учебный пример вызова с созданием подоболочки. Они также являются примерами узкоспециальных мини-языков императивного типа.

Dc — старейший язык в Unix. Он был создан на компьютере PDP-7 и перенесен на PDP-11 еще до того, как была перенесена (сама) Unix. Кен Томпсон.

Предметной областью данных языков являются арифметические вычисления неограниченной точности. Другие программы могут использовать их для выполнения таких вычислений, "не заботясь" о необходимых для этого специальных методиках.

Фактически первоначальная мотивация для создания dc не была связана с разработкой универсального интерактивного калькулятора, для которого было бы достаточно простой программы, поддерживающей вычисления с плавающей точкой. Мотивирующим фактором была давняя заинтересованность Bell Labs в численном анализе: точному вычислению констант для численных алгоритмов весьма способствует возможность работать с более высокой точностью, чем та, которую использует сам алгоритм. Отсюда и арифметика с неограниченной точностью в dc. Генри Спенсер.

Как и в случае SNG- и Glade-разметки одним из преимуществ обоих языков является их простота. Однажды узнав о том, что dc(1) — калькулятор с обратной польской записью, а bc(1) — калькулятор с алгебраической записью, пользователь найдет новыми очень немногие сведения об интерактивном использовании любого.

Из двух языков. Важность правила наименьшей неожиданности в интерфейсах повторно рассматривается в главе 11.

В обоих мини-языках имеются условные операции и циклы; они являются языками Тьюринга, но имеют очень ограниченную онтологию типов, включающую только целые числа неограниченной точности и строки, что ставит их между интерпретируемыми мини-языками и полными языками сценариев. Функции программирования реализованы так, чтобы не нарушать обычное использование программы в качестве калькулятора; в действительности, большинство пользователей dc/bc, вероятно, не подозревают о существовании этих функций.

Обычно программы dc/bc используются в диалоговом режиме, но их способность поддерживать библиотеки пользовательских процедур предоставляет им дополнительный вид служебных функций — программируемость. Фактически данное свойство является наиболее важным преимуществом императивных мини-языков, которое, как отмечалось в учебном примере по инструментарию Documenter's Workbench, должно быть очень мощным независимо от того, является ли обычный режим работы программы диалоговым. Данные языки можно использовать для написания высокоуровневых программ, которые включают в себя специализированную логику.

Поскольку интерфейс программ dc/bc прост (передается строка, содержащая выражение, в ответ на которую возвращается строка, содержащая значение), другие программы и сценарии могут легко получит доступ ко всем этим возможностям, вызывая dc/bc как подчиненные процессы. Ниже приводится один известный пример (см. пример 8.6), реализация шифра с открытым ключом Ривеста-Шамира-Адельмана (Rivest-Shamir-Adelman) на Perl, которая широко публиковалась в подписях почтовых сообщений и на футболках как протест против введенного в США в 1995 году ограничения на экспорт криптографических средств. Данный сценарий для выполнения необходимых арифметических расчетов с неограниченной точностью вызывает dc с созданием подоболочки.

Пример 8.6. RSA-реализация с помощью утилиты dc.

Print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack "H*", <>)]}\EsMsKsN0[1N*11K[d2%Sa2/d0<X+d*1MLa^*1N%0]dsXx++\ 1M1N/dsM0<J]dsJxp"|dc`

8.2.11. Учебный пример: Emacs Lisp.

Вместо того чтобы просто запускать интерпретируемый язык специального назначения в качестве подчиненного процесса для решения специфических задач, его можно использовать как основу для всей структуры. Преимущества и недостатки данного подхода рассматриваются в главе 13. Запросы troff были его ранним примером. Одним из самых известных и наиболее мощных современных примеров является редактор Emacs. Он создан на основе диалекта языка Lisp с примитивами как для описания действий в буферах редактирования, так и управления подчиненными процессами.

Тот факт, что Emacs построен вокруг мощного языка для описания редактирующих действий или клиентской части для других программ, означает, что он, кроме обычного редактирования, может применяться для многих других целей. Применение развитой, специализированной логики Emacs для повседневной разработки программ (компиляции, отладки, контроля версий) рассматривается в главе 15. "Режимы" Emacs представляют собой пользовательские библиотеки, т.е. программы, написанные на Emacs Lisp, которые приспосабливают редактор для решения специфической задачи, обычно (но не обязательно) связанной с редактированием.

Таким образом, существуют специализированные режимы, которые распознают синтаксис большого числа языков программирования и разметки, таких как SGML, XML и HTML. Однако многие пользователи также используют Emacs-режимы для отправки и получения электронной почты (в таких режимах в качестве подчиненных процессов используются почтовые утилиты Unix) или новостей Usenet. Emacs может служить в качестве Web-браузера или клиентской части для различных программ интерактивного общения. Существует также пакет для составления расписаний, собственная программа-калькулятор для Emacs и даже весьма широкий выбор игр, написанных как режимы Emacs Lisp.

8.2.12 Учебный пример: JavaScript.

JavaScript — язык с открытым исходным кодом, спроектированный для внедрения в C-программы. Несмотря на то, что он также встраивается в Web-серверы, первоначальным и наиболее известным его проявлением является клиентский JavaScript, который позволяет встраивать исполняемый код в Web-страницы, просматриваемые любым поддерживающим его браузером. Здесь рассматривается именно эта версия языка.

JavaScript — интерпретируемый язык, полностью попадающий под определения языка Тьюринга, с целыми, действительными числами, булевыми операторами, строками и легковесными, основанными на словарях, объектами, которые имеют сходство с объектами языка Python. Значения типизированы, но переменные могут иметь любой тип. Преобразование типов осуществляется автоматически во многих средах. Синтаксически JavaScript подобен языку Java с некоторым влиянием со стороны Perl и содержит функции для работы с Perl-подобными регулярными выражениями.

Несмотря на все указанные особенности, клиентская версия JavaScript не является полностью универсальным языком. Его возможности жестко ограничены в целях предотвращения атак на браузеры через Web-страницы, содержащие JavaScript-код. Язык принимает входные данные от пользователя и генерирует или модифицирует Web-страницы, но непосредственно не может изменять содержимое дисковых файлов и открывать собственные сетевые соединения.

С течением времени данный язык стал более универсальным и менее связанным со своей клиентской средой. Это закономерное развитие любого удачного специализированного языка. Клиентский вариант JavaScript в настоящее время взаимодействует со своим окружением путем чтения и записи значений в один специальный объект, который называется документной объектной моделью браузера (Document Object Model, DOM). Данный язык до сих пор имеет некоторые устаревшие API-интерфейсы для связи с браузером, которые не работают через DOM, однако они нежелательны, отсутствуют в стандарте для JavaScript ЕСМА-262 и могут не поддерживаться в будущих версиях.

Стандартным справочником по JavaScript является книга "JavaScript: The Definitive Guide" [20]. Исходный код доступен в Web[90]. Язык JavaScript представляет собой интересный пример для изучения по двум причинам. Во-первых, он максимально близок к универсальному языку, фактически не являясь таковым. Во-вторых, связь между клиентским JavaScript и средой браузера через единственный DOM-объект хорошо спроектирована и может послужить моделью для других ситуаций встраивания.

Оглавление.