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

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

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

for i in 1...n+1 loop -- создание каналов верх-низ

for j in 1..n loop

верх_низ(i,j) := new канал;

end loop;

end loop; -- ждут рабочих рандеву

. . . аналогично для каналов право_лево

!! НАСТРОЙКА !!

for i in 1..n loop -- настройка px

для_px(j).настройка(j, верх_низ(1,j));

-- рандеву с процессом-родителем

end loop; -- пошли первые рандеву с каналами

for i in 1..n loop -- настройка pb

для_pb(j).настройка (b(i), право_лево(i, n+1);

end loop;

for i in 1..n loop

for j in 1..n loop

для_pa.настройка (a(i,j),

верх_низ(i,j), право_лево(i,j+1),

верх_низ(i,j+1), право_лево(i,j));

end loop;

end loop;

. . . аналогично для py и p0

end координаты_2;

. . . все работает

[Между прочим, показан пакет с инициализирующими операторами,

расположенными между begin и end его тела. Эта последовательность операторов

работает в процессе "обработки" пакета (при его предвыполнении, при

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

Подводя итог, видим, что моделирование каналов существенно упрощает

описание и коммутацию коллективов однородных процессов. Каналы несложно

моделировать в Аде, вводя дополнительные процессы. При этом, в отличие от

нашего первого решения, не понадобились ссылки на "рабочие" процессы.

Вопрос. Почему?

Подсказка. Потому что их никому не нужно передавать.

Вопрос. Нельзя ли обойтись без ссылок на каналы?

Подсказка. Можно, если заставить процессы типа pa "знать" о различных

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

программу!).

Упражнение. Напишите соответствующий вариант программы.

[Обратите внимание: фактически удается передавать параметры-каналы

задачного типа. Процедурного типа в Аде нет. Наглядно видно, почему -

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

типов. А разных подпрограмм - может помешать!]

Упражнение. Найдите недостатки предложенного решения.

17.13. Отступление о задачных и подпрограммных (процедурных) типах

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

задачного типа, а обычный последовательный процесс (полпрограмма, процедура,

функциия) - не может быть объектом данных вообще (не считается объектом

какого-либо типа, "не имеет типа"). Поэтому, в частности, асинхронный

процесс может быть параметром процедуры (и функции), а процедура и функция -

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

переменные и параметры таких типов.

Потребность в параметрах задачных типов была видна на примере

параллельного преобразования координат (объекты типов pa, px, py...

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

Подчеркнем, что если бы в Аде разрешалось ввести процедурный тип, то в

настройке достаточно было бы указать в качестве параметра процедуру-рандеву

нужного партнера и наше первое решение (без каналов) резко упростилось бы.

17.13.1. Входовые типы - фрагмент авторской позиции

Представим себе идеальное решение взаимодействия партнеров по

параллельному преобразованию координат (без каналов, в рамках ассиметричного

рандеву).

Ключевая идея. Наши трудности были связаны с различием типов

потенциальных партнеров. Однако при этом все процедуры-рандеву были вполне

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

(назначение) - принять передаваемое (справа или сверху) вещественное число,

а профиль имеет вид, например, (X : real) или просто (real), если не

указывать имя формального параметра.

Поэтому было бы идеально ввести "входовый" тип нужного рандеву, а в

каждом мастере-партнере объявить вход этого типа. Тогда клиента нужно было

бы настраивать не на мастеров (различных типов), а на конкретные их входы

(которые все одного входового типа). [И никаких вариантных записей и

операторов выбора (в зависимости от типа партнера)!].

Выразительные средства:

package координаты_3 is -- координаты-1 - без каналов

. . . -- координаты-2

- с каналами

entry type принять is (X : real); -- ключевой момент!

-- (Д1) в Аде этого нет! Предлагается так объявлять

-- входовый тип - частный случай подпрограммного типа.

. . .

task type pa is

entry настройка (a: in real; слева, снизу: принять);

-- (Д2) параметры типа "принять".

entry сверху, справа : принять;

-- (Д3) это две константы типа "принять" - входы процесса типа pa

end pa;

. . . -- аналогично типы указателей на py и p0

task type py is

entry справа: принять; -- (Д4) константа типа "принять"

end py;

task type p0 is

entry сверху: принять; -- константа типа "принять"

end p0;

. . . -- аналогично типы px, pb; но с учетом

-- "настройки" для других, внешних партнеров.

end координаты-3;

package body координаты_3 is

task body pa is

aij, xj, yi,... : real; -- по-старому

n_слева, n_снизу : принять;

-- (Д5) переменнные типа "принять"; в них запоминается

-- результат настройки

begin

accept настройка (a: in real; слева, снизу: принять) do

aij := a; n_слева := слева; n_снизу := снизу;

-- (S1) передается "дескриптор" конкретного входа

end настройка;

. . .

accept сверху (X : in real) do ...; --(S2) по-старому

. . .

accept справа (X : in real) do ...; -- по-старому

. . .

n_слева(yi); -- (S3) к нужному входу партнера слева, а

-- именно ко входу "справа", если настроить правильно.

. . .

n_снизу(xj);

end pa;

task body py is

. . .

begin

accept настройка (...) do ... end; -- для связей

-- с внешним миром, которые здесь не рассмотрены

. . .

accept справа (X : in real) do ... end;

. . .

end py;

. . . -- аналогично для p0

task body px is

. . .

n_снизу : принять;

begin

accept настройка (j: in integer; снизу: принять) do

. . . n_снизу := снизу;

end настройка;

. . .

n_снизу(x);

. . .

end px;

. . . -- аналогично pb

end координаты-3;

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

случаю "координаты-2". Но при этом для настройки, например, нормального

процесса типа pa с партнерами также типа pa достаточно применить оператор

для_pa(i,j).настройка(a(i,j), для_pa(i,j+1).справа,

для_pa(i,j-1).сверху);

при этом передаются константы типа "принять".

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

теле пакета, либо в использующем контексте. Например

with координаты_3; use координаты_3;

procedure преобразование_координат is

для_pa : array(1..n, 1..n) of ppa; -- создаются нужные

для_py : array(1..n) of ppy; -- константы типа "принять"

для_p0 : array(1..n) of pp0;

...-- запуск, затем настройка

end преобразование_координат; ]

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

координаты_2 и без переборов вариантов из координаты_1. Все это - за счет

"входового" типа "принять".

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

выразительные средства вполне "в духе Ады". Ниже постараемся обосновать

следующий тезис: подобные средства отсутствуют в Аде потому, что ее авторы

не заметили или не придали должного значения роли подпрограмм именно как

однородных входов-рандеву разнородных асинхронных процессов.

Другими словами, наш анализ выразительных средств Оккама и Ады выявил

возможную точку роста языка Ада. Тем самым, выявлена еще одна, возможно,

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

транспьютеров).

С другой стороны, мы намерены показать, что без учета такой потребности

(назовем ее потребностью во "входовых" или "сервисных" типах; последнее в

связи с тем, что определяется тип сервиса, тип услуги, предоставляемого(ой)

возможно разнородными мастерами) авторов Ады вполне можно понять - другие

роли подпрограмм достаточно хорошо обслуживаются имеющимися в Аде

средствами.

17.13.2. Обоснование входовых типов

Для начала проследим отношение к проблеме подпрограммных типов,

привлекая в качестве иллюстрации ее решение в ряде ЯП (от Алгола-60 до

Модулы-2).

В самом Алголе-60 было понятие класса параметров. В частности, был

подпрограммный класс (точнее, класс процедур и класс функций). При этом

ничего похожего на Д1 не было, в Д2 вместо ссылки на Д1 нужно было бы

указать класс параметров "слева" и "снизу" и только. В нашем случае этот

класс был бы procedure. Так как профиль не был фиксирован, то и статический

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

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

текст почти на Алголе-60):

procedure P(F2,F2); procedure F1,F2;

begin real a,b; bool k,l;

F1(a,b); F2(k,l); -- нельзя проверить в рамках P

end;

procedure P1(c,d); real c,d; ...

procedure P2(F,c,d); procedure F; bool c,d;

...

P(P1,P2); P(P2,P1); -- неверный вызов.

Еще пример

procedure P(F); procedure F;

begin

if B then F(a, b)

else F(c)

end;

procedure F1 (k, l); . . . ;

procedure F2; (m); . . . ; -- обе можно подставлять - контроль только

динамический.

В оригинальном (авторском) Паскале ситуация аналогична. В Алголе-68,

гда принята структурная совместимость типов (там они называются "видами"),

аналог Д1 не обязателен, нужные профили (структуры видов) указываются в

аналогах Д2 и Д3. При этом процедуры с аналогичными профилями считаются

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

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

том числе и рекурсивных ссылок).

В более поздних версиях Паскаля (в частности, в проектируемом новом

стандарте ИСО и в ЯП Модула-2, наследовавшем лучшие черты Паскаля), введен и

аналог Д1 в виде

type принять = procedure (real);

и аналог Д2, и аналог Д5. Так что можно писать аналогично S1 с тем же

смыслом.

Однако аналога Д3 и Д4 в этих языках нет. Самое интересное для нас в

том, что это вполне закономерно. Обратите внимание: мы ввели только частный

случай процедурного типа - тип процедур-входов. Они отличаются содержательно

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

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

этом процедуры-входы разнородных процессов способны играть аналогичные роли,

что видно уже в момент их программирования (как в рассмотреннои примере

координаты_3). Поэтому их роль можно и целесообразно назвать специальным

именем ("принять"), считая его именем типа таких входов.

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

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

типа в Аде (т.е. концепцией чисто именной согласованности типов). Важно, что

и формально при этом не требуется ничего лишнего. В задаче имеется

спецификация входа, где и указывается при необходимости его тип. Тем самым

доказана неформальная лемма: явное объявление "входовых" подпрограммных

типов точно вписывается в концепцию типов языка Ада. Обратите внимание, мы с

Вами разработали обоснованное предложение по модернизции Ады!

Упражнение. Найдите возражения против этого предложения.

Подсказка. Полезно рассмотреть не только (и не столько) возражения,

опирающиеся на статус Ады как международного стандарта (хотя и стандарты

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

целостности ЯП - ведь входовые типы должны быть не инородной, а естественной

частью ЯП, в полной мере оправдывающей свое появление в нем. Сверхзадача -

ощутить себя в роли авторов (весьма нетривиального) ЯП, обязанных принять

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

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