В.Ш. Кауфман - Языки программирования - концепции и принципы (1990) (1160787), страница 42
Текст из файла (страница 42)
type цвет is (белый, ... , коричневый);
package для_цвета is new перечисляемый_обмен (цвет);
package для_чисел is new целочисленный_обмен (INTEGER);
use для_цвета; для_чисел;
end обмен_чисел_цветов_строк;
Так что процедуру, аналогичную нашей процедуре "диалог", можно начинать так:
with обмен_чисел_цветов_строк; use обмен_чисел_цветов_строк;
procedure новый_диалог is ... ;
Однако правила видимости в Аде не позволяют так работать. Ведь в
процедуре "новый_диалог" будет непосредственно видимо лишь то, что объявлено
в пакете из указателя сокращений use. Так что нужные процедуры придется
указывать полным именем. Например
для_чисел.послать (...);
для_цветов.получить (...); и т.п.
Таким образом, пользователь вынужден знать не только имя пакета, но и
его содержимое, да к тому же вынужден применять длинные имена. Это явно не
входило в наши планы. Другими словами, мы не достигли нужного уровня
абстракции предоставляемой услуги.
Чтобы его достичь, необходимо в пакете для_чисел_цветов_строк применить
переименование всех нужных процедур из предопределенных пакетов. Например
procedure послать (элемент : out цвет;
поле : in размер_поля := для_цвета.подразумеваемое_поле;
нижний : in BOOLEAN := для_цвета.подразумеваемый_нижний)
renames для_цвета.послать;
И так для всех (!) нужных процедур.
Назовем отмеченную неприятность проблемой транзита импортированных имен
(ведь суть проблемы - в передаче заимствованных коротких имен через
промежуточный модуль). Эта проблема характерна и для других ЯП с развитым
управлением контекстом (например для Модулы-2, которой мы еще займемся). В
Аде она решена (в отличие от той же Модулы-2), хотя и с весомыми накладными
расходами.
Упражнени (повышенной трудности). Предложите и обоснуйте решение
проблемы транзита.
11.3.5. Выводы об абстрактной модели обмена
Итак, абстрактная модель Ады характеризуется:
1. Понятием файла, разграничением внешних и внутренних файлов и
предопределенным типом "файловый".
2. Развитым аппаратом связывания с файлами подходящих наборов операций,
представленным совокупностью пакетов с родовыми параметрами.
3. Однородностью файлов.
4. Полиморфизмом и вариаргументностью предоставляемых операций.
(Вариаргументность - это возможность применять процедуры с переменным числом
аргументов за счет подразумеваемых значений опущенных аргументов).
5. Форматированием, встроенным непосредственно в операции управления
обменом. (Отсутствует, например, аналог фортранского именованного формата).
Упражнения. Придумайте варианты развития реализованного нами диалога и
реализуйте его. В случаях, когда возникают сомнения в точной семантике
операций, самостоятельно опишите (и обоснуйте) нужное Вам уточнение эффекта
операции или воспользуйтесь литературой по Аде.
11.4. Программирование специальных устройств
Чтобы управлять специальным внешним устройством, необходимо иметь
соответствующую аппаратуру - само устройство и аппаратный адаптер,
связывающий подключаемое устройство с основным исполнителем. При этих
условиях новое устройство становится источником (и потребителем)
определенных воздействий на исполнитель (со стороны исполнителя). Так как
обычно внешнее устройство работает асинхронно с основным исполнителем,
целесообразно рассматривать его как задачу, с которой можно
взаимодействовать посредством аппаратных прерываний, специальных регистров,
выделенных адресов и т.п.Назовем такую задачу аппаратной.
Изменить принцип функционирования аппаратной задачи (перепрограммиро-
вать ее) часто практически невозможно или нецелесообразно. Будем считать его
фиксированным. С другой стороны, с точки зрения создаваемого комплекса
программ возможности обмена, предоставляемые аппаратной задачей, обычно
выглядят как возможности излишне низкого уровня (абстракции). Они излишне
детально отражают поведение устройства и весьма далеки от планируемых его
содержательных функций в создаваемой системе.
Единственный способ построить более содержательное (и вместе с тем
более абстрактное) устройство - создать программную модель устройства в виде
асинхронного процесса, взаимодействующего с аппаратной задачей. Такая
программная модель называется драйвером устройства.
При создании драйвера естественно моделировать аппаратные регистры и
адреса данными подходящих типов, использовать спецификацию представления для
привязки этих данных к конкретным компонентам аппаратуры, а аппаратные
прерывания использовать для синхронизации драйвера с аппаратной задачей,
связывая входы драйвера с адресами соответствующих аппаратных прерываний.
Итак, общий метод программирования специальных внешних устройств
сводится к построению подходящего драйвера. При этом оказываются полезными
развитые типы данных и спецификации их представления.
Важно понимать, что специфицировать представление приходится не только
для привязки к адресам и структуре регистров. Так, перечисляемые типы удобны
в модели-драйвере, но их обычно аппаратура не воспринимает. Поэтому часть
работы, в обычных условиях "отдаваемой на откуп" компилятору, приходится
делать вручную, выписывая явно конкретные коды для значений перечисляемого
типа. Например
type защита is (обычная, ограниченная, строго_ограниченная, секретная,
совершенно_секретная);
for защита use (обычная => 0, ограниченная => 1, строго_ограниченная =>
2, секретная => 4, совершенно_секретная => 8);
В результате гарантируется, что драйвер передаст аппаратуре вполне
определенные числовые коды, предусмотренные ее конструкцией.
Рассмотрим пример драйвера из [17]. Символ, вводимый с клавиатуры,
вырабатывает прерывание с адресом 8#100# и выдачей соответствуюшего символа
в буферный регистр. (Человек за клавиатурой играет роль аппаратной задачи).
Напишем драйвер, который сохраняет введенный символ в локальной
переменной, доступной из любой обслуживаемой задачи по входу "взять_символ".
task драйвер_клавиатуры is
entry взять_символ (симв : out символьный);
entry есть_символ; -- аппаратное прерывание
for есть_символ use at 8#100#;
end драйвер_клавиатуры;
-- драйвер позволяет обслуживаемой задаче быть независимой
-- от конкретных адресов и прерываний и в этом смысле
-- служит абстрактной моделью клавиатуры.
task body драйвер_клавиатуры is
символ : символьный; -- рабочая переменная
буф_регистр : символьный;
for буф_регистр use at 8#177462#;
-- так элементы аппаратуры представляются данными
-- адовских типов
begin
loop
accept есть_символ do символ := буф_регистр end есть_символ;
accept взять_символ (симв : out символьный) do
симв := символ;
end взять_символ;
end loop;
end драйвер_клавиатуры;
Достигнув в цикле оператора приема "есть_символ", драйвер ждет
аппаратного прерывания. Предварительно он обязан разрешить его и заслать в
вектор адресов прерываний ссылку на тело оператора приема этого входа.
Делать все это обязана реализация оператора приема аппаратного входа в Аде.
Отличить аппаратный вход можно по спецификации его представления.
После прерывания тело оператора приема выполняется (происходит
аппаратно-программное рандеву). И драйвер готов обслужить "машинно-
независимую" задачу по входу "взять_символ". Здесь рандеву самое обычное.
Далее все повторяется в бесконечном цикле.
Итак, при программировании специального устройства потребовалось:
построить модель аппаратной задачи (в нашем случае она представлена
переменной буф_регистр и входом есть_символ);
связать эту модель с конкретной аппаратурой (в нашем случае - две
спецификации представления);
построить на основе аппаратной модели содержательную модель устройства
- задачу-драйвер.
Теперь можно пользоваться драйвером в качестве специального устройства
обмена в прикладных программах.
Упражнение. Разберитесь на примерах управления специальными
устройствами в книгах Пайла [17] и Янга[18]. Убедитесь, что в них явно или
неявно присутствуют и аппаратная модель, и связывание, и драйвер.
На этом закончим построение модели А (а тем самым изучение основных
абстракций современного индустриального ЯП с технологической позиции -
изученные аспекты Ады и составили модель А).
12. Два альтернативных принципа создания ЯП
12.1. Принцип сундука
Построив модель А, мы достигли переломного момента книги. До сих пор
накапливалось знание о технологических потребностях и удовлетворяющих эти
потребности языковых конструктах. Теперь накоплено достаточно материала,
чтобы взглянуть на него критически, с позиции автора современного ЯП.
И раньше мы не забывали об авторской позиции, выделяли концепции и
конструкты, помогающие создавать ЯП, анализировать и оценивать его. Однако
эти принципы и концепции, как правило, касались отдельных групп конструктов.
Наша ближайшая крупная цель - указать на два принципа, касающихся ЯП в
целом, и обсудить их влияние на современное языкотворчество.
Для краткости и выразительности дадим им названия "принцип сундука" и
"принцип чемоданчика".
На примере Ады мы видели, как выявляемые технологические потребности
приводили к новым конструктам. Может показаться, что на этом пути будут
получаться все более высококачественные ЯП. К сожалению, большинство
современных индустриальных ЯП носят на себе родимые пятна такого
примитивного критерия качества. Это характерно и для Кобола, и для ПЛ/1, и
для Фортрана-77, и для Ады.
Основной принцип конструирования, которым руководствовались авторы этих
ЯП, в упрощенной форме можно сформулировать так: для каждой значимой в ПО
технологической потребности в ЯП должно быть готовое выразительное средство.
Короче: каждой значимой потребности - готовый конструкт. Этот принцип
заготовленности конструктов и назовем принципом сундука (именно в сундуках
хранят много всякого на всякий случай).
Как показывает опыт, безудержное применение принципа сундука ведет к
громоздким, сложным, дорогим в реализации, обучении и использовании языкам-
монстрам с тяжеловесным базисом и несбалансированными средствами развития.
Сундук и есть сундук!
12.2. Закон распространения сложности ЯП
Бывают взаимодействия, сложность которых по существу не зависит от
собственной сложности взаимодействующих объектов. Например, процесс и
результат столкновения человека с автомобилем в первом приближении никак не
связаны со сложностью человека и автомобиля. Сложность вызова процедуры
непосредственно не связана с ее внутренней сложностью и сложностью
вызывающего контекста. В подобных ситуациях сложность инкапсулирована.
Образно говоря, простота взаимодействия обеспечивается "небольшой площадью"
взаимодействия потенциально весьма сложных объектов. ЯП сам служит
"поверхностью" взаимодействия авторов, реализаторов, преподавателей,
пользователей ЯП.
Такая специфическая роль ЯП определяет справедливость для него
следующего закона (распространения сложности) : собственная сложность ЯП
распространяется на все аспекты его "жизни" (описание, реализацию,
использование, обучение и т.д.). Никлаус Вирт отмечает частный случай этого
закона [19] как самое главное, что следует усвоить о реализации ЯП.
[Н.Вирт - один из самых авторитетных специалистов по ЯП, лауреат премии
Тьюринга за создание таких известных ЯП, как Алгол W, Паскаль, Модула,
Модула-2, профессор Высшей Технической школы в Цюрихе.]
Итак, ориентация на принцип сундука повышает собственную сложность ЯП,
что по закону распространения сложности приводит к росту сложности его
освоения (которая, в свою очередь, может оказаться катастрофической для его
судьбы - достаточно сопоставить судьбу Паскаля с судьбой Алгола-68).
Вспомним, однако, что основной принятый нами критерий качества базового
ЯП - его способность снижать сложность, помогать в борьбе с основной
проблемой программирования. Налицо тупик, в который ведет принцип сундука.
Вирту принадлежит принцип, указывающий выход из этого тупика.
12.3. Принцип чемоданчика
Н.Вирт неоднократно отмечал, что самое трудное при создании ЯП -
решить, от чего следует отказаться. Объясняя принципы конструирования своего
(теперь уже предпоследнего) ЯП Модула-2 (поразившего специалистов эле-
гантностью), Вирт развил эту идею и сформулировал следующий принцип
языкового минимума: в ЯП следует включать только такие концепции и
конструкты, без которых совершенно невозможно обойтись.
Назовем этот принцип минимума принципом чемоданчика по контрасту с
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
