Языки программирования концепции и принципы (стр. 18 )

Система типов в ЯП - это всегда система классификации денотатов (в общем случае и данных, и операций, и связываний; возможно, и других сущностей). Задачи такой классификации зависят от назначения языка, а также от других причин (отражающих, в частности, специфику ЯП как явления не только научно-технического, но и социального).

На систему типов в Аде влияет, конечно, специфика встроенных систем программного обеспечения (в особенности требование повышенной надежности, эффективности объектной программы и относительное богатство ресурсов инструментальной машины). Но некоторые свойства этой системы явно предписаны техническими требованиями заказчика и не могли быть изменены авторами языка.

Таким образом, излагаемые ниже принципы построения системы типов в Аде нужно воспринимать как интересный и в целом дееспособный вариант классификации обрабатываемых данных, но отнюдь не как окончательное единственно верное решение. Элегантная теория типов предложена и воплощена в ЯП Атлант [8,9].

4.2.1. Динамические, статические и относительно статические ЯП

Некоторые свойства объекта и связи с другими объектами остаются неизменными при любом исполнении его области действия (участка программы, где этот объект считается существующим). Такие свойства и связи называются статическими. Их можно определить по тексту программы, без ее исполнения.

Например, в Паскале тип объекта (целый, вещественный, логический) - одно из статических свойств. Сама область действия объекта - по определению статическое его свойство. Связь двух объектов по свойству принадлежать одной области действия - статическая связь. Свойство объекта при любом исполнении области действия принимать значения только из фиксированной совокупности значений - статическое свойство. Исчерпывающий перечень применимых к объекту операций - статическое свойство.

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

Например, конкретное значение переменной – динамическое свойство. Связь формального параметра с конкретным фактическим в результате вызова процедуры - динамическая связь. Размер конкретного массива с переменными границами - динамическое свойство.

Часто статические и динамические характеристики называют соответственно характеристиками периода компиляции (периода трансляции) и периода выполнения, подчеркивая то обстоятельство, что в период компиляции исходные данные программы недоступны и, следовательно, динамические характеристики известны быть не могут. Известны лишь характеристики, извлекаемые непосредственно из текста программы и тем самым относящиеся к любому ее исполнению (т. е. статические характеристики).

Однако деление на статические и динамические характеристики иногда оказывается слишком грубым. Например, размер массива в Алголе-60 может в общем случае изменяться при различных исполнениях его области действия, однако при каждом конкретном исполнении этот размер зафиксирован при обработке объявления (описания) массива и в процессе исполнения области действия изменяться не может. Так что это и не статическая характеристика, и вместе с тем не столь свободно изменяемая, как например, значение компоненты массива в Алголе-60, которое можно изменить любым оператором присваивания. Такие характеристики, которые могут меняться от исполнения к исполнению, но остаются постоянными в течение одного исполнения области действия объекта, будем называть относительно статическими.

Иногда пользуются и еще более тонкой классификацией характеристик по фактору изменчивости. Например, связывают изменчивость не с областью действия объекта, а с периодом постоянства других его избранных характеристик (выделяемого объекту пространства, связи с другими объектами и т. п.).

Уровень изменчивости характеристик допустимых денотатов - одно из важнейших свойств ЯП. Одна крайняя позиция представлена концепцией неограниченного (образно говоря, "разнузданного") динамизма, когда по существу любая характеристика обрабатываемого объекта может быть изменена при выполнении программы. Такая концепция не исключает прогнозирования и контроля, но не связывает их жестко со структурой текста программы.

Неограниченный динамизм присущ не только практически всем машинным языкам, но и многим ЯП достаточно высокого уровня. Эта концепция в разной степени воплощена в таких динамических ЯП, как Бейсик, Алл, Лисп, отечественных ИНФ и Эль-76 [10,11]. Идеология и следствия динамизма заслуживают отдельного изучения.

Другая крайняя позиция выражена в стремлении затруднить программисту всякое изменение характеристик денотатов. Вводя знак, нужно объявить характеристики денотата, а использование знака должно соответствовать объявленным характеристикам. Конечно, "неограниченной" статики в программировании добиться невозможно (почему?). Так что всегда разрешается менять, например, значения объявленных переменных.

Зато остальные характеристики в таких статических ЯП изменить трудно. Обычно стремятся к статике ради надежности программ (за счет дополнительной избыточности, при обязательном объявлении характеристик возникает возможность дополнительного контроля) и скорости объектных программ (больше связываний можно выполнить при трансляции и не тратить на это времени в период исполнения).

Вместе с тем сама по себе идея объявления характеристик (прогнозирования поведения) и контроля за их инвариантностью требует создания, истолкования и реализации соответствующего языкового аппарата. Поэтому статические ЯП, как правило, сложнее динамических, их описания объемнее, реализации тяжеловеснее. К тому же надежды на положительный эффект от статики далеко не всегда оправдываются. Тем не менее среди массовых языков индустриального программирования преобладают статические. Раньше это частично можно было объяснить трудностями эффективной реализации дина­мических ЯП. Сейчас на первое место выходит фактор надежности, и с этой точки зрения "старые" статические ЯП оказываются "недостаточно статическими" - аппарат прогнозирования и контроля у них связан скорее с требуемым распределением памяти, чем с други­ми характеристиками поведения, существенными для обеспечения надежности (содержательными ролями, изменчивостью значений, применимыми операциями и т. п.). С этой точки зрения интересен анализ возможностей динамических ЯП, в частности Эль-76, содер­жащийся в [11].

Ада принадлежит скорее к статическим, чем к динамическим ЯП, ее можно назвать языком относительно статическим с развитым ап­паратом прогнозирования-контроля. Концепция типа в Аде предназ­начена в основном для прогнозирования-контроля статических ха­рактеристик. Ее дополняет концепция подтипа, предназначенная для прогнозирования-контроля относительно статических характеристик. В дальнейшем мы будем рассматривать эти концепции вместе, счи­тая концепцию подтипа составной частью концепции типа.

4.2.2. Система типов как знаковая система

Постановка задачи. На стр 53-54 мы выделили семь факторов, ха­рактеризующих данные: роль в программе, строение, изменчивость, способ определения, представление, доступ, применимые операции. ЯП как знаковая система, предназначенная для планирования пове­дения исполнителя (в частности, для планирования его манипуля­ций с данными), может как иметь, так и не иметь специальные по­нятия и конструкты, позволяющие программисту характеризовать данные.

Крайняя позиция - полное или почти полное отсутствие таких средств. Пример - нормальные алгоритмы Маркова и другие модели, которые мы еще рассмотрим, а также Лисп, Форт, Апл, где нельзя охарактеризовать данные ни по одному из семи факторов. Конечно, эти факторы существенны независимо от применяемого ЯП. Просто при проектировании программы на ЯП без специальных средств классификации данных программист вольно или невольно использу­ет для характеристики данных внеязыковые средства (держит "в уме", отражает в проектной документации и т. п.).

Кое-что из такой "внешней" классификации находит воплощение и в программе. Но если находит, то часто в такой форме, что про­граммиста не могут проконтролировать не только компьютер, но и коллеги-программисты (да и он сам делает это, как правило, с тру­дом).

Указанная крайняя позиция игнорирует потребность прогнозиро­вания-контроля. Она характерна для ранних машинных ЯП и в чис­том виде в современном программировании не встречается.

Вспоминая пример с пошаговой детализацией и принцип согласо­вания абстракций, можно почувствовать, что тенденция к развитым средствам описания данных - естественная тенденция в современных ЯП, ориентированных на создание надежных и эффективных про­грамм с ясной структурой.

Допустим, что эта тенденция осознана. Возникает следующая за­дача - какие ключевые концепции должны быть положены в основу средств описания данных? Если угодно, как построить "язык в язы­ке", знаковую систему для характеристики данных в ЯП?

Первый вариант: перечни атрибутов. По-видимому, первое, что приходит в голову, - ввести свои средства для характеристики каж­дого фактора и сопровождать каждый объект перечнем характери­стик.

Примерно так сделано в ПЛ/1. Объявляя переменную, в этом ЯП можно перечислить ее характеристики (так называемые "атрибуты") по многим факторам (основание системы счисления, способ пред­ставления, способ выделения памяти, структура и способ доступа к компонентам, потребуется ли печатать значения и т. п.).

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

Во-первых, довольно утомительно задавать длинные перечни ат­рибутов при объявлении данных. Из-за этого в ПЛ/1 придуманы да­же специальные "правила умолчания" атрибутов (это одна из самых неудачных и опасных с точки зрения надежности концепция ПЛ/1, к тому же этих правил много, они сложны, так что запомнить их невозможно).

Во-вторых, один перечень атрибутов - у данного, а другой (тоже достаточно длинный) перечень - у формального параметра процеду­ры. Может ли такое данное быть фактическим параметром? Чтобы это понять, нужно сравнить оба перечня, потратив время и рискуя ошибиться (компьютер ошибиться не рискует, но ему это тоже доро­го обходится). И дело не только (и не столько) в самом переборе ат­рибутов, сколько в сложности правил, определяющих применимость процедуры к данному.