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

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

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

задачного типа могут быть объявлены подходящие базовые операции. Все

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

типами данных, причем данных активных, а не пассивных.

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

типов. Например, можно объявить массив из десяти анализаторов.

А: array (1..10) of анализ;

и обращаться к соответствующим входам с помощью индексации

А(1).прими ...; ...; А(10).прими ...

Задачные объекты могут, естественно, быть и динамическими. Например,

можно ввести ссылочный тип

type Р is access анализ;

и переменную R типа Р

R : Р;

Теперь понятно действие оператора

R := new анализ;

А именно, создается новый асинхронный процесс типа "анализ" и ссылка на

него помещается в R. К соответствующему входу можно теперь обращаться через

R.прими ...

Подчеркнем, что у динамических задачных объектов не может быть

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

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

объектов.

Формально тело задачи отличается от тела процедуры лишь тем, что в

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

обычной процедуры.

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

процессами много и плодотворно занимался Бринч-Хансен. Интересующегося

читателя отсылаем к [13]. Практическим результатом исследований проблем

параллелизма еще одним классиком информатики Тони Хоаром стал язык

параллельного программирования Оккам. Ему (точнее, его последней версии

Оккам-2), посвящен специальный раздел.

7. Нотация

7.1. Проблема знака в ЯП

Вспомним, что ЯП - знаковая система. Но знаковая ситуация возникает

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

Как отправителем, так и адресатом может оказаться и человек, и компьютер.

ЯП должен быть средством мышления людей, создающих программы, средством их

общения между собой по поводу создания программ; средством общения людей с

компьютерами и, наконец, компьютеров между собой. Для людей важно, чтобы

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

чтения. Необходимость общаться с компьютерами предъявляет к знакам особые

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

ввода и выводить устройствами вывода. К тому же они должны восприниматься

имеющейся в распоряжении программной средой.

Указанные требования весьма разнообразны и порой противоречивы.

Привычных людям знаков часто нет на устройствах ввода-вывода. Может

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

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

вводить рукописный текст (хотя в будущем это наверняка станет возможным).

Итак, даже если в знаковой ситуации, соответствующей ЯП,

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

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

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

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

ЯП в национальном (тем более мировом) масштабе, то возникает самостоятельная

серьезная проблема - проблема знака.

В этом разделе мы сконцентрируемся лишь на части этой большой проблемы:

проблеме представления знаков (проблеме нотации).

7.2. Определяющая потребность

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

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

можно было ввести в любой компьютер без особых затрат и риска внести ошибки.

Назовем ее потребностью совместимости по вводу. Эта потребность -

определяющая в том смысле, что ради ее удовлетворения в современной ситуации

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

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

шрифтов, управление цветом, нелинейная запись и т.п.).

Другими словами пишущий программу (отправитель знака) должен иметь

возможность абстрагироваться от особенностей устройств ввода у адресата. С

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

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

отправителем.

7.3. Основная абстракция

Абстракция, обслуживающая потребность совместимости по вводу, хорошо

известна - это абстрактный (эталонный) текст. Понятие эталонного текста

определено в каждом ЯП. Эталонный текст - это конечная последовательность

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

Он называется алфавитом ЯП. Потребность в совместимости удовлетворяется за

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

является знаком программы. Именно он подразумевается, когда работают на

конкретном устройстве ввода-вывода.

Но на конкретном устройстве свой алфавит. Так что приходится

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

доступными на устройстве, а эталонный текст в целом - конкретным текстом

(составленным из конкретных символов). Так, эталонные символы Алгола-60

(begin, end и т.п.) обозначаются иногда "BEGIN", "END", иногда _begin_,

_end_, иногда `НАЧАЛО', `КОНЕЦ' и т.п.

Таким образом, конкретный текст обозначает эталонный, а тот, в свою

очередь, обозначает программу.

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

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

средства конкретизации. Проблема нотации дает пример, когда средства

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

проблему конкретизации эталонного текста.

7.4. Проблема конкретизации эталонного текста

Обычно в ЯП отсутствуют средства управления связью конкретных и

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

обозначены некоторыми текстами, их также нужно вводить и выводить. Короче,

для них возникнут те же проблемы, что и для ЯП в целом. Так что решать

проблему конкретизации приходится вне ЯП.

Тем более важно принять рациональные решения, определяющие правила

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

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

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

конкретизации. Они ввели три уровня языка - эталонный, для публикаций и

конкретные представления. Первый был ориентирован "исключительно на

взаимопонимание", второй - на "типографские особенности", третий - на

устройства ввода-вывода. Что касается проблемы конкретизации, то авторы

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

перевода конкретных представлений в эталонные".

Именно "правила", а не программы и не программные изделия для перевода!

Затраты ресурсов на такой перевод и риск внести ошибки не оценивались и не

контролировались. На практике это привело к несовместимости различных

трансляторов с Алгола-60. Так как реализаторы не только не подкрепляли

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

осознавали "правила". Проблема несовместимости реализаций, в свою очередь,

сыграла не последнюю роль в том, что Алгол-60 не сумел выдержать конкуренцию

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

расчетов.

Итак, допустим, что важность проблемы конкретизации осознана. Как

рационально решить эту проблему?

7.5. Стандартизация алфавита

Игнорировать проблему нельзя, управлять конкретизацией невозможно.

Остается по существу единственный путь - стандартизация алфавита (или

определение ЯП со стандартным алфавитом).

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

рассматриваемого ЯП и выбирается опорный стандарт на цифровые коды символов

(достаточно распространенный, лучше всего - международный). Эталонный

алфавит ЯП определяется через опорный стандарт (по существу, эталонным

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

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

управляющие символы образуют допустимые конкретные алфавиты). Тем самым

определяются и допустимые вариации конкретных алфавитов (рамками того же

опорного стандарта).

С одной стороны, авторы ЯП вынуждены выбирать из стандартного набора

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

программирования вынуждены считаться с действующими стандартами и

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

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

цифровым кодам (например, А - 101, В - 102, 0 (нуль) - 60, 1 - 61 в коде

ASCII и т.п.). Таким образом, на некотором этапе обработки текст обязательно

представлен стандартной последовательностью числовых кодов. Ее и следует

считать эталонным текстом. Именно такой эталонный текст и обеспечивает

практическую совместимость по вводу.

Стандартизация алфавита требует коллективных усилий международного

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

компьютеров и периферийных устройств. Но зато и уровень совместимости по

вводу в ЯП со стандартизированным алфавитом зависит не от распространенности

конкретной реализации языка, а от распространенности опорного стандарта.

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

организаций по стандартизации в настоящее время существуют достаточно

авторитетные стандарты на символы (7- и 8-битовый международные стандарты

ИСО и соответствующие национальные стандарты, в том числе и отечественный

ГОСТ). Так что создана приемлемая база для разработки ЯП со стандартным

алфавитом.

Рост технических возможностей и, соответственно, потребностей

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

(например, чтобы можно было работать с цветом или с различными шрифтами).

Тогда появится больше возможностей и у авторов ЯП. Вместе с тем потери от

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

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

естественна.

Для ЯП со стандартным алфавитом нет особого смысла различать эталонные

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

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

Первым ЯП со стандартным алфавитом был Фортран. В настоящее время этот

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

считать общепринятым.

7.6. Основное подмножество алфавита

Еще одна заслуживающая внимания идея (позволяющая работать на "бедных"

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

состоит в выделении так называемого основного подмножества алфавита. При

этом в определении ЯП фиксируются правила изображения остальных символов

алфавита с помощью комбинаций символов из основного подмножества. Написанный

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

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

В любой "богатой" реализации ЯП можно (и нужно) иметь средства для

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

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

существенно помогает "бедным".

7.7. Алфавит языка Ада

Текст исходной программы в Аде - это последовательность символов.

Символы делятся на графические и управляющие. Каждому символу однозначно

соответствует 7-битовый код ИСО. Вариации графических символов возможны

только в рамках, допустимых стандартом ИСО для национальных стандартов

(например, знак доллара можно заменить знаком фунта стерлингов). Управляющие

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

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

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