В.Ш. Кауфман - Языки программирования - концепции и принципы (1990) (1160787), страница 15
Текст из файла (страница 15)
В заключение подчеркнем, что указанные факторы ортогональны.
Классификация не претендует на полноту, но позволит ориентироваться, в
частности, в системе управления данными в Аде. Дополнительные факторы
классификации предложены, например, в языке Том [7].
4.2. Типы данных
Классификация данных присутствует в каждом ЯП. В Алголе-60 она отражена
в системе классов и типов (классы - процедуры, метки, простые переменные,
массивы, переключатели; типы - целый, вещественный, логический), в Фортране
- также в системе классов и типов (классы имен - массив, переменная,
внутренняя функция, встроенная функция, внешняя функция, подпрограмма,
переменная и общий блок; типы - целый, вещественный, двойной точности,
комплексный, логический, текстовый). В более современных ЯП имеется
тенденция полнее отражать классификацию данных в системе типов, а само
понятие типа данных меняется от языка к языку.
Система типов в ЯП - это всегда система классификации денотатов (в
общем случае и данных, и операций, и связываний; возможно, и других
сущностей). Задачи такой классификаци зависят от назначения языка, а также
от других причин (отражающих, в частности, специфику ЯП как явления не
только научно-технического, но и социального).
На систему типов в Аде влияет, конечно, специфика встроенных систем
программного обеспечения (в особенности требование повышенной надежности,
эффективности объектной программы и относительное богатство ресурсов
инструментальной машины). Но некоторые свойства этой системы явно предписаны
техническими требованиями заказчика и не могли быть изменены авторами языка.
Таким образом, излагаемые ниже принципы построения системы типов в Аде
нужно воспринимать как интересный и в целом дееспособный вариант
классификации обрабатываемых данных, но отнюдь не как окончательное
единственно верное решение. Элегантная теория типов предложена А.В.Замулиным
и воплощена в ЯП Атлант [8,9].
4.2.1. Динамические, статические и относительно статические ЯП.
Некоторые свойства объекта и связи с другими объектами остаются
неизменными при любом исполнении его области действия (участка программы,
где этот объект считается существующим). Такие свойства и связи называются
статическими. Их можно определить по тексту программы, без ее исполнения.
Например, в Паскале тип объекта (целый, вещественный, логический) -
одно из статических свойств. Сама область действия объекта - по определению
статическое его свойство. Связь двух объктов по свойству принадлежать одной
области действия - статическая связь. Свойство объекта при любом исполнении
области действия принимать значения только из фиксированной совокупности
значений - статическое свойство. Исчерпывающий перечень применимых к объекту
операций - статическое свойство.
Другие свойства и связи изменяются в процессе исполнения области
действия. Их называют динамическими.
Например, конкретное значение переменной - динамическое свойство. Связь
формального параметра с конкретным фактическим в результате вызова процедуры
- динамическая связь. Размер конкретного массива с переменными границами -
динамическое свойство.
Часто статические и динамические характеристики называют соответственно
характеристиками периода компиляции (периода трансляции) и периода
выполнения, подчеркивая то обстоятельство, что в период компиляции исходные
данные программы недоступны и, следовательно, динамические характеристики
известны быть не могут. Известны лишь характеристмки, извлекаемые
непосредственно из текста программы и тем самым относящиеся к любому ее
исполнению (т.е. статические характеристики).
Однако деление на статические и динамические характеристики иногда
оказывается слишком грубым. Например, размер массива в Алголе 60 может в
общем случае изменяться при различных исполнениях его области действия,
однако при каждом конкретном исполнении этот размер зафиксирован при
обработке объявления (описания) массива и в процессе исполнения области
действия изменяться не может. Так что это и не статическая характеристика, и
вместе с тем не столь свободно изменяемая, как например, значение компоненты
массива в Алголе 60, которое можно изменить любым оператором присваивания.
Такие характеристики, которые могут меняться от исполнения к исполнению, но
остаются постоянными в течение одного исполнения области действия объекта,
будем называть относительно статическими.
Иногда пользуются и еще более тонкой классификацией характеристик по
фактору изменчивости. Например, связывают изменчивость не с областью
действия объекта, а с периодом постоянства других его избранных
характеристик (например, выделяемого объекту пространства или связи с
другими объектами (каналами ввода-вывода и т.п.)).
Уровень изменчивости характеристик допустимых денотатов - одно из
важнейших свойств ЯП. Одна крайняя позиция представлена концепцией
неограниченного (образно говоря "разнузданного") динамизма, когда по
существу любая характеристика обрабатываемого объекта может быть изменена
при выполнении программы. Такая концепция не исключает прогнозирования и
контроля, но не связывает их жестко со структурой текста программы.
Неограниченный динамизм присущ не только практически всем машинным
языкам, но и многим ЯП достаточно высокого уровня. Эта концепция в разной
степени воплощена в таких динамических ЯП, как Бейсик, Апл, Лисп,
отечественные ИНФ и Эль-76 [10,11]. Идеология и следствия динамизма
заслуживают отдельного изучения.
Другая крайняя позиция выражена в стремлении затруднить программисту
всякое изменение характеристик денотатов. Вводя знак, нужно объявить
характеристики денотата, а использование знака должно соответствовать
объявленным характеристикам. Конечно, "неограниченной" статики в
программировании добиться невозможно (почему?). Так что всегда разрешается
менять, например, значения объявленных переменных.
Зато остальные характеристики в таких статических ЯП изменить трудно.
Обычно стремятся к статике ради надежности программ (за счет дополнительной
избыточности при обязательном объявлении характеристик возникает возможность
дополнительного контроля) и скорости объектных программ (больше связываний
можно выполнить при трансляции и не тратить на это времени в период
исполнения).
Вместе с тем сама по себе идея объявления характеристик
(прогнозирования поведения) и контроля за их инвариантностью требует
создания, истолкования и реализации соответствующего языкового аппарата.
Поэтому статические ЯП, как правило, сложнее динамических, их описания
объемнее, реализации тяжеловеснее. К тому же надежды на положительный эффект
от статики далеко не всегда оправдываются. Тем не менее среди массовых
языков индустриального программирования преобладают статические. Раньше это
частично можно было объяснить трудностями эффективной реализации
динамических ЯП. Сейчас на первое место выходит фактор надежности, и с этой
точки зрения "старые" статические ЯП оказываются "недостаточно статическими"
- аппарат прогнозирования и контроля у них связан скорее с требуемым
распределением памяти, чем с другими характеристиками поведения,
существенными для обеспечения надежности (содержательными ролями,
изменчивостью значений, применимыми операциями и т.п.). С этой точки зрения
интересен анализ возможностей динамических ЯП, в частности, Эль 76,
содержащийся в [11].
Ада принадлежит скорее к статическим, чем к динамическим ЯП, ее можно
назвать языком относительно статическим с развитым аппаратом
прогнозирования-контроля. Концепция типа в Аде предназначена в основном для
прогнозирования-контроля статических характеристик. Ее дополняет концепция
подтипа, предназначенная для прогнозирования-контроля относительно
статических характеристик. В дальнейшем мы будем рассматривать эти концепции
вместе, считая концепцию подтипа составной частью концепции типа.
4.2.2. Система типов как знаковая система
Постановка задачи. Мы выделили семь факторов, характеризующих данные:
роль в программе, строение, изменчивость, способ определения, представление,
доступ, применимые операции. ЯП как знаковая система, предназначенная для
планирования поведения исполнителя (в частности, для планирования его
манипуляций с данными) может как иметь, так и не иметь специальных понятий и
конструктов, позволяющих программисту характеризовать данные.
Крайняя позиция - полное или почти полное отсутствие таких средств.
Пример - нормальные алгоритмы Маркова и другие модели, которые мы еще
рассмотрим, а также Лисп, Форт, Апл, где нельзя охарактеризовать данные ни
по одному из семи факторов. Конечно, эти факторы существенны независимо от
применяемого ЯП. Просто при проектировании программы на ЯП без специальных
средств классификации данных программист вольно или невольно использует для
характеристики данных внеязыковые средства (держит "в уме", отражает в
проектной документации и т.п.).
Кое-что из такой "внешней" классификации находит воплощение и в
программе. Но если находит, то часто в такой форме, что программиста не
может проконтролировать не только компьютер, но и коллеги-программисты (да и
он сам делает это, как правило, с трудом).
Указанная крайняя позиция игнорирует потребность прогнозирования-
контроля. Она характерна для ранних машинных ЯП и в чистом виде в
современном программировании не встречается.
Вспоминая пример с пошаговой детализацией и принцип согласования
абстракций, можно почувствовать, что тенденция к развитым средствам описания
данных - естественная тенденция в современных ЯП, ориентированных на
создание надежных и эффективных программ с ясной структурой.
Допустим, что эта тенденция осознана. Возникает следующая задача -
какие ключевые концепции должны быть положены в основу средств описания
данных? Если угодно, как построить "язык в языке", знаковую систему для
характеристики данных в ЯП?
4.3.3. Первый вариант : перечни атрибутов.
Повидимому, первое, что приходит в голову - ввести свои средства для
характеристики каждого фактора и сопровождать каждый объект перечнем
характеристик.
Примерно так сделано в ПЛ/1. Объявляя переменную, в этом ЯП можно
перечислить ее характеристики (так называемые "атрибуты") по многим факторам
(основание системы счисления, способ представления, способ выделения памяти,
структура и способ доступа к компонентам, потребуется ли печатать значения и
т.п.).
Такая знаковая система, как показывает опыт, вполне дееспособна, однако
с точки зрения ясности и надежности программ оставляет желать лучшего.
Во-первых, довольно утомительно задавать длинные перечни атрибутов при
объявлении данных. Из-за этого в ПЛ/1 придуманы даже специальные "правила
умолчания" атрибутов (это одна из самых неудачных и опасных с точки зрения
надежности концепция ПЛ/1, к тому же этих правил много, они сложны, так что
запомнить их невозможно).
Во-вторых, один перечень атрибутов - у данного, а другой (тоже
достаточно длинный) перечень - у формального параметра процедуры. Может ли
такое данное быть фактическим параметром? Чтобы это понять, нужно сравнить
оба перечня, потратив время и рискуя ошибиться (компьютер ошибиться не
рискует, но ему это тоже дорого обходится). И дело не только (и не столько)
в самом переборе атрибутов, сколько в сложности правил, определяющих
применимость процедуры к данному.
Итак, запомнив, что у проблемы два аспекта - прогноз (описание) и
контроль (проверка допустимости поведения данных), поищем другие решения.
(Отметим, что по отношению к ЯП мы сейчас колеблемся между технологической и
авторской позициями, задевая семиотическую).
Второй вариант: структурная совместимость типов. Воспользуемся
принципом обозначения повторяющегося. Заметили, что часто приходится иметь
дело с перечнями атрибутов? Значит, нужно обозначить повторяющийся перечень
некоторым именем и упоминать это имя вместо самого перечня. Следовательно,
нужен языковый конструкт для объявления таких имен.
Естественно считать, что имя обозначает не только сам перечень
атрибутов, но и класс данных, обладающих объявленными характеристиками. Мы
пришли к понятию типа данных как класса объектов-данных, обладающих
известными атрибутами. А искомый языковой конструкт - это объявление типа
данных. Его назначение - связывать объявляемое имя с указанным перечнем
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
