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

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

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

жизни". Однако можно попытаться построить ЯП, на базе которого будет удобно

(относительно несложно, с приемлемыми затратами) строить модели весьма

разнообразных ПО. Такой язык называют базовым языком программирования.

Обычная схема применения базового языка в определенной ПО состоит из

двух этапов. На первом (инструментальном) создается модель ПО и

соответствующий ПОЯ (их создают с помощью базового языка программисты-

конструкторы). На втором (функциональном) этапе программисты-пользователи

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

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

с компьютером, а не планируют поведение заранее. Соответственно и

пользователей такого ПОЯ обычно программистами не называют.

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

ПОЯ со своей ПО - он предназначен для построения моделей других ПО и

соответствующих ПОЯ. В дальнейшем будем рассматривать именно базовые ЯП -

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

1.21. Концептуальная схема рассмотрения ЯП

Завершая подготовку к систематическому изучению ряда моделей ЯП,

зафиксируем единую схему их рассмотрения. Эта схема поможет сопоставить и

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

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

Если бы нас интересовала, например, оценка ЯП с точки зрения легкости

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

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

наиболее подходящих средств решения этих проблем и т.д., подобно нашему пути

к базовому языку.

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

демонстрацию существенного элемента систематического метода сравнительной

оценки языков. (Конечно, наша учебная схема намного проще той, которую

следовало бы строить при практическом решении вопроса о пригодности

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

Главное назначение базового языка - строить модели ПО с тем, чтобы

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

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

контроль.

Первое средство будем кратко называть аппаратом развития (так как по

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

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

конкретизации).

Второе средство будем называть аппаратом защиты (так как оно

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

Исключительная технологическая роль названных средств дает основание

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

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

будет корректироваться и уточняться.

Итак, в каждом ЯП нас будет интересовать три аспекта: базис, аппарат

развития (развитие), аппарат защиты (защита).

Базис ЯП - это предопределенные (встроенные в ЯП) знаки и их денотаты.

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

операции (это так называемая скалярная сигнатура) и, во-вторых, структуры

данных и операций (структурная сигнатура).

Например, в Фортране к скалярной сигнатуре естественно отнести все пять

встроенных типов данных, перечень встроенных функций и все операторы. К

структурной сигнатуре относятся только массивы и модули. С некоторой

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

общие блоки, условные операторы.

Некоторые компоненты базиса составляют аппарат развития ЯП, некоторые -

аппарат защиты.

Об аппарате развития уже сказано. Добавим лишь, что будем различать

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

развитие вниз - уточнение и переопределение компонент базиса или ранее

определенных абстракций. Например, модуль-подпрограмма в Фортране - средство

развития вверх. А средств развития вниз в Фортране нет (в отличие от Ады, Си

или CDL).

Об аппарате защиты также уже сказано. Имеется в виду прогнозирование

(объявление) свойств поведения объектов (принадлежности к определенному

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

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

частности, управление реакцией на нарушение объявленного поведения).

Кроме базиса, развития и защиты будем рассматривать иногда другие

особенности ЯП и, в частности, особенности эталонного исполнителя ЯП (так

называемого языкового процессора) и архитектуру ЯП в целом. Например, для

Фортрана исполнитель последовательный, для Рефала - циклический, а для Ады -

параллельный.

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

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

согласованность решений), модульность, ортогональность (возможность свободно

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

выразительных средств) и т.п.

В заключение подчеркнем, что в нашей схеме - только внутренние аспекты

ЯП как знаковой системы. Совершенно не затронуты такие важнейшие для выбора

и оценки ЯП аспекты, как распространенность на различных типах компьютеров,

наличие высококачественных реализаций, уровень их совместимости и т.п.

2. Пример современного базового ЯП (модель А)

2.1. Общее представление о ЯП Ада

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

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

понятия будем демонстрировать на примере ЯП Ада. Он устраивает нас тем, что

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

- проблемы сложности, содержит понятия и конструкты, характерные для

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

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

полнота языка в том смысле, что в нем в той или иной форме можно получить

ответы на все вопросы современного практического программирования в

конкретной ПО. Вместе с тем эти ответы не следует рассматривать как истину в

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

Аде решений, так и совершенно иные подходы к программированию в целом.

В соответствии с принципом моделирования ЯП не будем изучать язык Ада

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

модель А.

Мы исходим из принципа технологичности - всякий языковый конструкт

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

этапах жизненного цикла комплексного программного продукта. Этот принцип, с

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

"заказчиков" понятий и конструктов ЯП. С другой стороны, он требует понимать

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

Желательно видеть связь этих понятий с общей идеей абстракции-конкретизации.

Будем подчеркивать эту связь, когда посчитаем существенной.

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

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

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

особенностях той ПО, для которой создавался ЯП Ада.

Область, в которой реально применяется ЯП, отнюдь не всегда

определяется намерениями его авторов (чаще всего она оказывается пустой!).

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

ЯП, взглянуть на язык как систему в какой-то мере согласованных решений,

почувствовать то, что называют "духом" языка. Иначе язык покажется

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

Язык Ада создан в основном в 1975-1980 гг. в результате грандиозного

проекта, предпринятого МО США с целью разработать единый ЯП для так

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

комплексами, работающими в реальном времени). Имелись в виду прежде всего

бортовые системы управления военными объектами (кораблями, самолетами,

танками, ракетами, снарядами и т.п.). Поэтому решения, принятые авторами

Ады, не следует считать универсальными. Их нужно воспринимать в контексте

особенностей выбранной ПО.

Характерные требования таковы. Во-первых, необходимы особо надежные и

особо эффективные системы управления. Во-вторых, при развитии систем и

создании новых очень важно иметь возможность в максимальной степени

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

испытанные программы), т.е. программы должны быть относительно легко

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

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

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

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

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

этих частей. В-четвертых, речь идет о системах реального времени - такая

система должна управлять поведением реальных физических объектов, движущихся

и изменяющихся с весьма высокими скоростями. Таким образом, должна быть

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

(параллельные) процессы, представляющие такие объекты, и управлять их

взаимодействием.

Наконец, в-пятых, в этой области распространена так называемая кросс-

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

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

(целевой, объектной). Инструментальная машина обычно обладает существенно

более богатыми ресурсами, объектная (часто бортовая, т.е. находящаяся

непосредственно на управляемом объекте) - более бедными. Это обстоятельство

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

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

инструментальной машине).

Перечисленные характеристики ПО существенно повлияли на особенности

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

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

компиляции (учтены относительно богатые возможности инструментальной машины

и бедность объектной). Предусмотрены и возможности оптимизации объектной

программы при компиляции (учтены различия инструментальной и объектной машин

с точки зрения возможностей обеспечить эффективность встроенных систем).

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

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

средства управления асинхронными процессами. Итак, определяющие требования к

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

параллелизм.

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

проходившего в 1978-1979гг. Участники должны были удовлетворить довольно

жестким, детально разработанным под эгидой МО США требованиям. Интересно,

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

Паскале. В этой связи Аду можно предварительно охарактеризовать как Паскаль,

развитый с учетом перечисленных выше пяти основных требований. При этом

авторы (международный коллектив под руководством Ишбиа) пошли в основном по

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

существенно более сложный язык.

Пример простой программы на Аде

Чтобы создать у читателя первое зрительное впечатление об Аде, дадим

пример совсем простой (но полной) программы. Основой этого (и некоторых

других наших примеров) послужили программы из учебника Янга "Введение в Аду"

[2].

Напишем программу, которая вводит последовательность символов со

стандартного устройства ввода и на стандартном устройстве вывода печатает

левые и правые скобки, обнаруженные в этой последовательности.

Вот эта программа:

1. with т_обмен;

2. procedure печать_скобок is

3. ch : символ ;

4. begin

5. т_обмен.дай (ch) ;

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

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