В.Ш. Кауфман - Языки программирования - концепции и принципы (1990) (1160787), страница 13

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 13)

интереснее случай, когда интерпретатор реализован программой. Программа эта

написана, конечно, на каком-то языке программирования M. Будем считать, что

M отличен от L. Программная реализация интерпретатора интересна именно

потому, что в этом случае интерпретатор представлен написанным на языке M

текстом-программой и вполне можно ожидать, что в общем случае из этого

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

Например, программы компилятора и суперкомпилятора, также написанные на

языке M.

Мы намерены делать это посредством специализатора s. Для определенности

будем считать, что программа-специализатор s также написана на языке M,

применима к текстам программ, написанным на M и выдает в качестве

результатов программы, написанные все на том же языке M.

Специализация интерпретатора. Посмотрим, что собой представляет s(i,p),

т.е. во что специализатор s превращает интерпретатор i после его связывания

с конкретной программой p? (Ведь i - форма от двух аргументов, так что

специализатор s к ней применим; при этом в соответствии со смыслом s с i

связывается первый аргумент интерпретатора - p, а второй остается свободным

параметром). Применяя (**), получим

s(i,p)(d) = i(p,d) = r.

[Обратите внимание, чтобы выписать результат специализатора, нужно

"передвинуть" функциональные скобки на позицию вправо и опустить символ

специализатора].

Другими словами, s(i,p) - это такая программа p', которая после

применения к данным d дает результат r. Следовательно, p' эквивалентна

программе p. Но p' написана уже на языке M, а не на L! Следовательно, p' -

это перевод программы p на язык M. Итак, связав интерпретатор (написанный на

языке M) с исходной программой на языке L, получили ее перевод на M.

Кратко это можно выразить так: специализация интерпретатора по

программе дает ее перевод.

[Подумайте, что в общем случае можно сказать о качестве полученного

перевода - скорости работы, объеме памяти; а что - о скорости перевода?]

Специализация специализатора. Итак, при различных i специализатор дает

переводы с разных языков. Нетрудно теперь догадаться, что при фиксированном

i специализатор s представляет собой компилятор с языка L на язык M. Ведь,

как мы видели, в этом случае он по заданной p получает ее перевод p'.

Действительно, посмотрим, что такое s(s,i)? Вновь применяя (**), получим

s(s,i)(p) = s(i,p).

Но ведь s(i,p) это p', перевод программы p на язык M! Так что s(s,i) -

(написанный на M) это компилятор KLM с языка L на язык M.

Кратко выразим это так: специализация специализатора по интерпретатору

дает компилятор. Или еще короче: автоспециализация по интерпретатору дает

компилятор.

[Снова есть повод подумать о возможном качестве компилятора и затратах

на его получение в общем случае].

Двойная автоспециализация. Специализатор может выступать и в роли

суперкомпилятора. Ведь по заданному интерпретатору i (который можно считать

описанием языка L), специализатор выдает компилятор с языка L на язык M.

Действительно, посмотрим, что такое s(s,s)? Опять применяя (**), получим

s(s,s)(i) = s(s,i).

Но ведь s(s,i) = KLM! Так что s(s,s) - это действительно

суперкомпилятор над языком M (в свою очередь написанный на M).

Кратко выразим это так: двойная автоспециализация дает суперкомпилятор.

Вопрос. Нельзя ли получить что-либо интересное тройной

автоспециализацией?

Подсказка. А что если подставлять различные воплощения специализатора

s?

Три последовательных применения специализатора удобно наглядно выразить

следующей серией соотношений

s(s,s)(i)(p)(d) = s(s,i)(p)(d) = s(i,p)(d) = i(p,d) = r.

Другими словами, s(s,s) воспринимает описание языка L (т.е. i) и выдает

компилятор s(s,i), который в свою очередь воспринимает исходную программу p

на языке L и выдает ее перевод s(i,p), который уже воспринимает исходные

данные d и выдает результат r.

Таким образом, мы убедились, что абстракция связывания (точнее,

частичное связывание) позволяет с единых позиций рассмотреть важнейшие

понятия теории трансляции и вывести полезные закономерности. Именно, связав

i с p, получили перевод; связав s с i, получили компилятор; связав s с s -

суперкомпилятор.

[Строго говоря, мы имеем здесь дело не с суперкомпилятором, а с более

универсальной программой.

Вопрос. В чем это проявляется?].

[Приведеннные выше соотношения называют соотношениями Футамуры-Турчина.

Способ их изложения позаимствован у С.А.Романенко]

Замечание (о сущности трансляционных понятий). Хотя непосредственное

практическое значение соотношений Футамуры-Турчина пока проблематично, они

помогают увидеть заманчивые перспективы, а также четче выделять понятия.

Действительно, обычно отличие, например, интерпретации от компиляции

формулируют несколько расплывчато. Говорят, что интерпретатор воспринимает

исходную программу вместе с исходными данными и выполняет ее последовательно

"шаг за шагом", в соответствии с операционной семантикой языка L.

Операционной называют семантику, выраженную через последовательность

действий исполнителя, соответствующую каждому тексту на L.

Вопрос. Можно ли иными средствами задать семантику ЯП? Предложите свои

средства.

Написание интерпретаторов на машинных или ранее реализованных языках -

хорошо известный, естественный и для многих целей удобный способ реализации

ЯП. Для некоторых из них (Лисп, Апл, Бейсик) - единственный способ полной

реализации. Это справедливо для всех языков, в которых программа может

меняться в процессе исполнения - только "шаг за шагом" и можно уследить за

таким изменением.

Когда говорят о компиляции, подразумевают перевод всей программы как

целого, без учета конкретных исходных данных, с исходного языка L на

объектный язык M. С конкретными исходными данными исполняется уже результат

такого перевода.

Такого рода содержательные различия, конечно, существенны, однако

значительная их часть улавливается на формальном уровне, нам теперь вполне

доступном. Ведь интерпретатор - это форма с двумя аргументами, а компилятор

- с одним. Интерпретатор - это (ограниченный) аппликатор, а компилятор - это

преобразователь программ (сохраняющий их смысл).

Вот пример пользы от рассмотрения языковых концепций (связывания) с

математической позиции.

Важно понимать, что формальные преобразования специализатора в

компилятор и суперкомпилятор не отражают некоторых содержательных аспектов

этих понятий. Обычно компилятор применяют ради повышения скорости работы

переведенных программ по сравнению с интерпретацией. Специализатор же в

общем случае может выдать остаточную программу, состоящую в сущности из

интерпретатора и обращения к нему. В таком случае неоткуда ждать выигрыша в

скорости. При попытках "оптимизировать" такую программу за счет раскрытия

циклов и т.п. она может стать непомерно длинной. Аналогичные соображения

касаются и суперкомпилятора. Тем не менее в указанном направлении получены

обнадеживающие результаты для частных видов специализаторов [4,5].

Не до конца улавливается приведенными соотношениями и сущность

компиляции. Она в переводе на другой язык, на котором может оказаться вовсе

невозможно или очень невыгодно писать интерпретатор исходного языка L

(например, это невозможно делать на небольшой встроенной бортовой машине). А

ведь в наших соотношениях все программы (кроме p) написаны на объектном

языке M. Сказанное не означает, что в подобных случаях непригодна

математическая позиция. Просто нужны и другие математические модели

компиляции. Например, проекционная, где компилятор рассматривается как

реализация проекции (отображения языка L на M), а не как специализация

написанного на M интерпретатора (последнего может и не существовать).

На этом закончим обсуждение связывания как самостоятельной абстракции.

Как видим, оно оказалось весьма емким, глубоким понятием, взаимодействующим

со многими концепциями программирования.

3.5. Принцип цельности

Считая достаточно обоснованной самостоятельную ценность каждой из трех

выделенных абстракций, продемонстрируем на их примере один весьма общий

принцип проектирования, который назовем принципом цельности. Его называют

также принципом концептуальной целостности.

Суть принципа цельности в том, что детали проекта в идеале должны быть

следствием относительно небольшого числа базисных, ключевых решений. Другими

словами, в цельном проекте большинство деталей можно предсказать, зная

базисные решения. Содержательно это означает, что проект выполнен на основе

цельной концепции, единого замысла, а не представляет собой нагромождение

случайностей.

Покажем, как принцип цельности проявляется на трех уровнях рассмотрения

программного проекта, два из которых - языковые.

Первый уровень - собственно программа(?)(?)Сначала несколько совсем

общих соображений. Проектирование - это сочетание абстракции и конкретизации

(принимая конкретное проектировочное решение, тем самым одновременно вводят

абстракции нижнего уровня, предназначенные для реализации принятого решения

- вспомните появление новых имен при проектировании пакета

управление_сетью). Цельная концепция в идеале должна воплощаться

согласованными абстракциями, а отсутствие таковой проявляется в их

несогласованности.

Согласованность (абстракций) понимается как удобство их совместного

использования для удовлетворения определяющих потребностей.

Возвратимся к трем выделенным абстракциям. Заметим, что иметь с ними

дело приходится независимо от того, насколько сознательно они выделяются в

технологическом цикле проектирования программ. Покажем, как принцип

цельности позволяет выработать естественные критерии качества языковых

конструктов.

[Следующие ниже соображения носят весьма общий, почти философский

характер. Это естественно, так как рассматривается один из общих принципов

"философии программирования". Вместе с тем получаются вполне осязаемые

критерии и оценки].

В соответствии с принципом технологичности (который справедлив не

только для ЯП, но и для создаваемых с их помощью программ), выделяемые

абстракции призваны обслуживать определенные технологические потребности.

Проявим критерии цельности ЯП с точки зрения потребностей пошаговой

детализации.

Применяя эту технологию, следует исходить из хорошо понятной постановки

задачи. Однако в понятной постановке задачи компонент мало. Следовательно,

они содержательные, емкие, имеющие непосредственную связь с сутью решаемой

задачи. Но тогда и операнды у этих операций обладают теми же свойствами. И

их связывание должно опираться на средства доступа к таким емким операциям и

данным. По мере детализации операций менее емкими становятся и операнды, и

средства связывания.

Итак, в процессе пошаговой детализации свойства данных, операций и

связывания должны на каждом шаге быть взаимно согласованными по степени

детализации.

Упражнение. Проверьте это утверждение на нашем примере с сетями.

Обратите внимание на возможность вводить содержательные понятия, не

сомневаясь в возможности их реализации средствами ЯП.

Второй уровень - средства программирования. Следовательно, чтобы

обеспечить технологические потребности пошаговой детализации, языковые

конструкты должны обслуживать согласование указанных свойств на каждом шаге

детализации. Мы пришли к важному критерию качества языковых конструктов: в

хорошем ЯП конструкты, обслуживающие определение и использование каждой из

упомянутых абстракций, должны быть согласованы по степени управления

детализацией.

Упражнение. Приведите примеры нарушения этого требования в известных

вам ЯП.

Подсказка. В Паскале функции вырабатывают только скалярный результат -

нет прямого средства сопоставить "емкой" функции согласованную по "емкости"

структуру данных. Например, нельзя определить функцию все_связи. Уже

упоминалось отсутствие развитых средств связывания с контекстом.

Третий уровень - средства развития. Подчеркнем важный момент.

Содержательные абстракции на каждом шаге детализации зависят от решаемой

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

создаются ПОЯ. Это и есть задача, решаемая с помощью базового языка. Решать

ее также естественно методом пошаговой детализации (иногда его называют

методом абстрактных машин). Например, мы создали абстрактную машину,

работающую с сетью. Ее команды - наши пять операций доступа к сети. При

реализации этой машины используется (но не оформлена нами явно), машина

удаления связей. Никлаусу Вирту принадлежит глубокая мысль о том, что

истинное назначение ЯП - предоставить средства для ясного и точного

определения абстрактных машин. Следовательно, в базовых языках должны быть

согласованными между собой и средства развития всех трех разновидностей

абстракций. Другими словами, в ЯП, претендующем на универсальность, принцип

цельности в идеале призван работать при проектировании как базиса ЯП, так и

средств его развития.

Упражнение. Приведите примеры нарушения этого требования в известных

Характеристики

Список файлов книги