Запись алгоритмов на языке программирования паскаль 9 класс босова

N. Wirth
Institut fur Computersysteme. ETH Zurich CH-8092 Цюрих Абстрактный

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

Содержание

Ранняя история
Язык
Более Поздние Разработки
В Ретроспективе
Признания
Ссылки

Ранняя история

Язык программирования Паскаль был разработан в 1968/69 годах. И я назвал его в честь французского философа и математика. Который в 1642 году создал одно из первых устройств. Которое действительно можно было бы назвать цифровым калькулятором. Первый компилятор для языка Pascal был введен в эксплуатацию в начале 1970 года. И тогда же было опубликовано определение языка [Wirth, 1970]. Эти факты, по — видимому. Составляют опорные точки истории Паскаля.

Однако его подлинные истоки уходят гораздо дальше. Возможно, столь же интересно пролить некоторый свет на события и тенденции времени. Предшествовавшего его рождению. Как и рассказать о шагах. Приведших к его широкому использованию. Поэтому я начну с более или менее хронологического описания ранней истории Паскаля. В начале 1960-х годов существовало два основных научных языка: Фортран и алгол 60 [Naur, 1963]. Первый уже широко использовался и поддерживался крупными производителями компьютеров. Последний – разработанный международным комитетом экспертов по вычислительной технике – не имел такой поддержки. Но привлекал внимание своей систематической структурой и кратким формализованным определением.

Было очевидно. Что Алгол заслуживает большего внимания и более широкого поля применения. Чтобы достичь этого. Алголу требовались дополнительные конструкции. Делающие его пригодным для целей. Отличных от численных вычислений. С этой целью IFIP учредила Рабочую группу с уставом по определению преемника Algol. Была надежда. Что нежелательный каньон между научным и коммерческим программированием. К середине 1960-х годов воплощенный как миры Фортрана и Кобола. Может быть преодолен.

Я имел честь присоединиться к Рабочей группе 2.1 в 1964 году. Несколько встреч с кажущимися бесконечными дискуссиями об общей философии языкового дизайна. О методах формального определения. О синтаксических деталях. Наборах символов и целом спектре тем. Связанных с программированием. Выявили обескураживающее отсутствие консенсуса относительно подхода. Который следует принять. Однако богатство представленных идей и опыта также послужило стимулом для объединения их в мощный ансамбль. По мере того как число заседаний росло. Стало очевидно. Что из примерно двух десятков членов Рабочей группы возникли две основные фракции.

Одна партия состояла из честолюбивых членов, не желавших опираться на рамки Алгола 60, не боявшихся создавать элементы. Которые в значительной степени не были опробованы и последствия которых для разработчиков оставались предметом спекуляций. И стремившихся воздвигнуть еще одну веху. Подобную той. Которую установил Алгол 60. Противники оказались более прагматичными. Они стремились сохранить корпус алгола 60 и расширить его хорошо понятными функциями. Расширяя область применения предполагаемого языка-преемника. Но сохраняя упорядоченную структуру его предка. В этом духе было предложено добавление основных типов данных для действительных чисел двойной точности и для комплексных чисел. А также структуры записи. Известной из COBOL. Замена вызова по имени Algol параметром call-by-reference и замена чрезмерно общего for-оператора Algol ограниченной. Но более эффективной версией.

Они не решались включить новые. Непроверенные идеи в официальный язык. Прекрасно понимая. Что в противном случае веха может легко превратиться в жернов. В 1965 году мне было поручено представить РГ предложение. Которое отражало взгляды прагматиков. Однако на заседании в октябре того же года большинство членов одобрило конкурирующее предложение. Представленное А. ван Вейнгарденом, бывшим членом команды Algol 60, и решило выбрать его в качестве основы для Algol X на встрече в Варшаве осенью 1966 года [van Wijngaarden, 1969].

К сожалению. Как и предполагали многие. Сложность Algol 68 вызвала много задержек. В результате чего на момент его внедрения в начале 70-х годов многие пользователи Algol 60 уже приняли другие языки [Hoare, 1980]. Я приступил к реализации своего собственного предложения. Несмотря на его отклонение. И включил концепцию динамических структур данных и привязки указателя. Предложенную CAR.

Хоэр. Реализация была сделана в Стэнфордском университете для нового компьютера IBM 360. Проект был поддержан грантом Национального научного фонда США. Результат был опубликован и стал известен как Algol W [Wirth, 1966]. Эта система была принята во многих университетах для преподавания курсов программирования. Но язык оставался ограниченным компьютерами IBM 360/370. По сути, Algol W расширил Algol 60 новыми типами данных. Представляющими двойные точные числа с плавающей запятой и комплексные числа. С битовыми строками и динамическими структурами данных. Связанными указателями.

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

Прошлый опыт дал мне пожизненное недоверие к продуктам комитетов. Где многие участвуют в обсуждении и принятии решений. А немногие выполняют реальную работу. Затрудняемую многими. В 1968 году я стал профессором в Федеральном технологическом институте в Цюрихе (ETH). Где Algol 60 был языком выбора среди исследователей числовых вычислений. Приобретение компьютеров CDC в 1965 году (и тем более в 1970 году) сделало это предпочтение трудно оправданным. Поскольку компиляторы Algol для этих компьютеров были довольно плохо спроектированы и не могли конкурировать с их аналогами Fortran. Кроме того, задача обучения программированию – в частности системному программированию – оказалась крайне непривлекательной. Учитывая выбор между Fortran и ассемблерным кодом в качестве единственных доступных инструментов.

В конце концов. Настало время не только проповедовать достоинства структурированного программирования. Но и сделать их применимыми на практике. Предоставив язык и компиляторы. Предлагающие соответствующие конструкции. Дисциплина структурированного программирования была изложена Э. У. Дейкстрой [Dijkstra 1966] и представляла собой важный шаг вперед в борьбе с тем. Что стало известно как кризис программного обеспечения.

Чувствовалось. Что дисциплина должна преподаваться на уровне вводных курсов программирования. А не как запоздалая мысль при попытке переобучить старые руки. Это понимание остается в силе и сегодня. Структурированное программирование и поэтапное уточнение [Wirth 1971a] положили начало методологии программирования и стали краеугольным камнем. Позволившим программному проектированию стать предметом интеллектуальной респектабельности. Следовательно. Определение нового языка и разработка его компилятора были не просто исследовательским проектом в языковом дизайне. А скорее тупой необходимостью.

Ситуация повторялась несколько раз в последующие десятилетия. Когда лучшим советом было: Не имея адекватных инструментов. Стройте свои собственные! В 1968 году цели были двоякими: язык должен был быть пригоден для краткого и логичного выражения известных в то время фундаментальных конструкций. А его реализация должна была быть эффективной и конкурентоспособной с существующими компиляторами Fortran. Последнее требование оказалось довольно сложным. Учитывая компьютер (CDC 6000). Который был разработан во многом с учетом Фортрана. В частности. Динамические массивы и рекурсивные процедуры представляли собой серьезные препятствия и поэтому были исключены из первоначального проекта языка.

Запрет рекурсии был ошибкой и вскоре должен был быть исправлен. В должном признании того. Что неразумно подвергаться сильному влиянию неадекватного инструмента преходящего характера. Задача написания компилятора была возложена на одного аспиранта (Э. Мармье) в 1969 году. Поскольку его опыт программирования был ограничен Fortran. Компилятор должен был быть выражен на Fortran. С его переводом на Pascal и последующей самокомпиляцией. Запланированной после его завершения.

Это, как оказалось. Было еще одной серьезной ошибкой. Неспособность языка Фортран выразить сложные структуры данных компилятора привела к искажению программы. И ее перевод был перепроектирован. Поскольку структуры. Присущие проблеме. Стали невидимыми в формулировке языка Фортран. Компилятор опирался на синтаксический анализ. Основанный на управляемой таблицей схеме Изощренность синтаксического анализа была в моде в 1960-е годы. Предположительно из-за мощи и гибкости. Необходимых для обработки высокоуровневых языков. Тогда мне пришло в голову. Что можно было бы использовать гораздо более простой и понятный метод. Если бы синтаксис языка выбирался с учетом процесса его анализа.

Поэтому вторая попытка создания компилятора началась с его формулировки на самом исходном языке. Который к тому времени превратился в то. Что было опубликовано как Pascal в 1970 году [Wirth, 1970]. Компилятор должен был быть однопроходной системой. Основанной на проверенном принципе нисходящего рекурсивного спуска для синтаксического анализа. Отметим здесь. Что этот метод был приемлемым. Поскольку запрет на рекурсию был снят: рекурсивность процедур должна была быть нормальным случаем. Команда разработчиков состояла из У. Аммана. Э. Мармьера и Р. Шильда.

После завершения программы – здоровый опыт программирования на нереализованном языке! – Шильд был сослан в свой дом на две недели, время. Которое потребовалось ему. Чтобы перевести программу на вспомогательный. Низкоуровневый язык. Доступный на компьютере CDC. После этого может начаться процесс начальной загрузки [Wirth, 1971b]. Этот компилятор был завершен к середине 1970 года. И в это время было опубликовано определение языка. За исключением некоторых незначительных изменений в 1972 году. Он оставался стабильным и после этого. Мы начали использовать язык Паскаль на вводных курсах программирования в конце 1971 года.

Поскольку ETH предложил программу по информатике только десять лет спустя. Использование Pascal для обучения программированию инженеров и физиков вызвало определенную полемику. Мой аргумент состоял в том. Что требование преподавать методы. Используемые в промышленности. В сочетании с тем фактом. Что промышленность использует методы. Преподаваемые в университетах. Составляет порочный круг. Препятствующий прогрессу. Но, вероятно. Это была моя упрямая настойчивость. А не какой-либо разумный аргумент. Который удерживал Паскаля в использовании.

Десять лет спустя никто не возражал. Чтобы помочь преподавателю. Кэти Дженсен начала писать учебник. Объясняющий основные понятия программирования на языке Паскаль с помощью множества примеров. Этот текст был впервые напечатан как Технический отчет. А затем появился в серии лекционных заметок Шпрингера-Верлага [Jensen, 1974].

Язык

Главная роль языкового дизайнера — это роль разумного собирателя признаков или понятий. После того. Как эти понятия выбраны. Должны быть найдены формы их выражения. То есть должен быть определен синтаксис. Формы, выражающие отдельные понятия. Должны быть тщательно вылеплены в единое целое.

Это самое важное. Так как в противном случае язык будет казаться бессвязным. Как скелет. На который были привиты отдельные конструкции, возможно. Как после-мысли. Прошло достаточно времени. Чтобы основные недостатки Алгола были известны и могли быть устранены. Например, была признана важность избежания двусмысленности. Во многих случаях необходимо было принять решение. Следует ли раскрывать дело в ясной форме или оставаться совместимым с Алголом. Эти варианты иногда были взаимоисключающими. Оглядываясь назад. Можно сказать. Что решения в пользу совместимости были неудачными. Поскольку они сохраняли в живых недостатки прошлого.

Важность совместимости была переоцениваема. Как и значимость и размер сообщества Алгол-60. Примерами таких случаев являются синтаксическая форма структурированных высказываний без замыкающего символа. Способ указания результата процедуры функции (присвоение идентификатору функции) и неполная спецификация параметров формальных процедур. Все эти недостатки позже были исправлены в преемнике Паскаля Modula-2 [Wirth, 1982], например. Двусмысленное условное высказывание Алголя было сохранено. Считать

ЕСЛИ p, ТО ЕСЛИ q. ТО A ЕЩЕ B

который может. В соответствии с указанным синтаксисом. Интерпретироваться следующими двумя способами:

ЕСЛИ p, ТО [ЕСЛИ q. ТО A ЕЩЕ B]

ЕСЛИ p, ТО [ЕСЛИ q. ТО A] ЕЩЕ B

Паскаль сохранил эту синтаксическую двусмысленность. Выбрав, однако. Интерпретацию. Которая все ОСТАЛЬНОЕ будет ассоциироваться с ближайшим к нему слева. Средство защиты, известное. Но отвергнутое в то время. Состоит в требовании явного закрывающего символа для каждого структурированного утверждения. В результате чего для двух случаев используются две различные формы. Как показано ниже:

ЕСЛИ p, ТО ЕСЛИ q. ТО A ЕЩЕ B КОНЕЦ КОНЕЦ

IF p THEN
IF q THEN A END
ELSE B
END
Pascal также сохранил неполную спецификацию типов параметров формальной процедуры. Оставив открытой опасную лазейку для нарушения проверок типов. Рассмотрим декларации

ПРОЦЕДУРА P (ПРОЦЕДУРА q);
НАЧАЛО q(x,y) КОНЕЦ;

ПРОЦЕДУРА Q (x: REAL);
НАЧАЛО… КОНЕЦ;

и вызов P(Q). Затем q вызывается с неправильным количеством параметров. Которые вообще не могут быть обнаружены во время компиляции. В противовес таким уступкам традиции стояла ликвидация условных выражений. Таким образом. Символ, ЕСЛИ ясно. Становится маркером начала высказывания и сбивает с толку конструкции формы

ЕСЛИ p, ТО x:=ЕСЛИ q. ТО y ЕЩЕ z ЕЩЕ w

они изгнаны из языка.
Барочное for-утверждение Алгола было заменено укрощенной версией. Которая эффективно реализуема. Ограничивая управляющую переменную простой переменной и пределом. Который должен быть вычислен только один раз. А не перед каждым повторением. Для более общих случаев повторений было введено выражение while. Таким образом. Стало невозможно формулировать вводящие в заблуждение. Не заканчивающиеся утверждения. Как, например

ДЛЯ i:=0 ШАГ 1 ДО ТЕХ ПОР. ПОКА я НЕ СДЕЛАЮ S

и довольно неясная формулировка

более четко это можно было бы выразить словами

i :=n;

Основное новшество языка Паскаль состояло в том. Чтобы включить в него различные типы данных и структуры данных. Подобно тому. Как Алгол ввел множество структур операторов. Алгол предлагал только три основных типа данных. А именно целые числа. Действительные числа и истинностные значения. А также структуру массива; Паскаль ввел дополнительные базовые типы и возможность определять новые базовые типы (перечисления. Поддиапазоны). А также новые формы структурирования: запись. Набор и файл (последовательность). Некоторые из которых присутствовали в COBOL. Наряду с определенными программистом типами данных появилось четкое различие между определением типа и объявлением переменной. Переменные являются экземплярами типа.

Концепция строгой типизации. Уже присутствующая в Алголе. Стала важным катализатором безопасного программирования. Тип должен был пониматься как шаблон для переменных. Определяющих все свойства. Которые остаются неизменными в течение времени существования переменной. В то время как его значение изменяется (посредством присвоения). Диапазон возможных значений остается неизменным. Как и его структура. Эта эксплицитность статических свойств позволяет компиляторам проверять. Соблюдаются ли правила. Управляющие типами.

Привязка свойств к переменным в тексте программы называется ранним связыванием и является отличительной чертой языков высокого уровня. Поскольку дает четкое выражение намерению программиста. Не зависящему от динамики выполнения программы. Однако строгое следование понятию (статического) типа привело к некоторым менее удачным последствиям. Здесь мы имеем в виду отсутствие динамических массивов. Их можно понимать как статические массивы с числом элементов (или значениями ограничивающего индекса) в качестве параметра. Паскаль не включал параметризованные типы. Главным образом по причинам реализации. Хотя концепция была хорошо понятна.

В то время как отсутствие переменных динамического массива, возможно. Не было слишком серьезным. Отсутствие параметров динамического массива явно признается дефектом. Если не с точки зрения разработчика компилятора. То, конечно. С точки зрения программиста численных алгоритмов. Например, следующие объявления не позволяют вызывать процедуру P с x в качестве фактического параметра:

ТИП A0 = ARRAY [1 .. 100] OF REAL; A1 = ARRAY [0 .. 999] OF REAL;
VAR x: A1;
ПРОЦЕДУРА P(x: АО); НАЧАЛО … КОНЕЦ

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

В то время как в Algol W массивы могут быть объявлены только как статические переменные и. Следовательно. Доступны только напрямую. Запись структурированных переменных может быть доступна только через ссылки (указатели). То есть косвенно. В Pascal все структуры могут быть доступны либо напрямую. Либо через указатели. Причем косвенность определяется явным оператором разыменования. Это разделение интересов было известно как Введение явных указателей. То есть переменных указательного типа. Стало ключом к значительному расширению сферы их применения.

Используя указатели. Можно создавать динамические структуры данных. Как в языках обработки списков. Примечательно. Что гибкость в структурировании данных стала возможной без ущерба для строгой статической проверки типов. Это было связано с концепцией привязки указателя. То есть объявления каждого типа указателя как связанного с типом объектов. На которые ссылаются ссылки. Как это было предложено [Hoare, 1972]. Рассмотрим, например. Декларации

ТИП Pt = ^ Rec; Rec = ЗАПИСЬ x,y: РЕАЛЬНЫЙ КОНЕЦ; VAR p, q: Pt;

Тогда p и q. При условии. Что они были правильно инициализированы. Гарантированно содержат либо значения. Относящиеся к записи типа Rec. Либо константу NIL Оператор вида p^.x := p.y + q^.x оказывается таким же типобезопасным. Как и простой x := x +y.

Действительно. Указатели и динамические структуры были значительно важнее динамических массивов во всех приложениях. Кроме числовых вычислений. С указателями неразрывно связан механизм распределения памяти. Поскольку Pascal должен был подходить в качестве языка построения систем. Он старался не полагаться на встроенный механизм сборки мусора во время выполнения. Как это было необходимо для Algol W.

Принятое решение состояло в том. Чтобы предоставить новую внутреннюю процедуру для выделения переменной в области хранения. Называемой кучей. И дополнительную процедуру для освобождения (DISPOSE). NEW тривиально реализовать. А DISPOSE можно игнорировать. И действительно. Это оказалось разумным сделать. Потому что системные процедуры. Зависящие от информации программиста. По своей сути небезопасны. Идея предоставления схемы сбора мусора не рассматривалась ввиду ее сложности. Ведь наличие локальных переменных и определенных программистом типов и структур данных требует достаточно сложной и сложной схемы. Принципиально зависящей от целостности системы.

Коллектор должен быть в состоянии полагаться на информацию обо всех переменных и их типах. Эта информация должна быть сгенерирована компилятором и. Кроме того. Ее нельзя аннулировать во время выполнения программы. Тема методов передачи параметров уже была источником бесконечных споров и суеты в дни поиска преемника Алгола 60. Непрактичность его параметра имени была четко установлена. И необходимость параметра значения была общепринята. Тем не менее. Были веские аргументы для ссылочного параметра. В частности для структурированных операндов. С одной стороны. И веские причины для параметров результата-с другой.

В первом случае формальный параметр представляет собой скрытый указатель на фактическую переменную. Во втором-формальный параметр является локальной переменной. Которая назначается фактической переменной по окончании процедуры. Выбор опорного параметра (в Паскале VAR-parameter) в качестве единственной альтернативы параметру value оказался простым. Целесообразным и успешным.

И последнее. Но не менее важное: Паскаль включил утверждения для ввода и вывода. Отсутствие которых в Алголе было источником постоянной критики.

В частности. В отношении роли Паскаля как языка обучения была выбрана простая форма таких высказываний. Их первый параметр обозначает файл и. Если он опущен. Заставляет данные считываться или записываться на носитель по умолчанию. Такой как клавиатура и принтер. Причиной включения специального утверждения для этой цели в определение языка. А не постулирования специальных. Стандартных процедур. Было желание учесть переменное число и различные типы параметров:

Чтение(x.y);… ;Запись(x,y,z)

Как уже упоминалось ранее. Языковой дизайнер собирает часто используемые программные конструкции из своего собственного опыта. Из литературы или из других языков и формирует их в синтаксические формы таким образом. Что они вместе образуют единый язык.

В то время как основная структура Pascal происходит от Algol W. Многие из новых функций появились из предложений. Сделанных CAR. Hoare, включая перечисление. Поддиапазон. Набор и типы файлов. Форма подобных коболу типов записей возникла благодаря Хоару. А также идее представления “логических слов” компьютера с помощью хорошо известной абстракции. А именно множеств (малых целых чисел). Эти “обрывки” обычно представлялись и обсуждались на заседаниях Рабочей группы IFIP 2.1 (Algol). А затем появлялись в виде сообщений в бюллетене Algol.

Они были собраны в его Заметках по структурированию данных [Hoare, 1972]. В Паскале они были перегнаны в связную и последовательную структуру синтаксиса и семантики. Так что структуры были свободно комбинируемы. Паскаль допускает определения массивов записей. Записей массивов. Массивов множеств и массивов записей с файлами. Просто чтобы назвать несколько возможностей. Естественно. Реализации должны были бы налагать определенные ограничения на глубину вложенности из-за ограниченных ресурсов. И некоторые комбинации. Такие как файл файлов. Могут вообще не приниматься.

Этот случай может служить примером различия между общими понятиями. Определяемыми языком. И дополнительными. Ограничительными правилами. Регулирующими конкретные реализации. Хотя богатство типов данных и структурирующих форм было главным активом Pascal. Не все компоненты были одинаково успешными. Мы помним, что успех-это субъективное качество. И мнения могут сильно отличаться. Поэтому я концентрируюсь на Наиболее громкая критика исходила от Хабермана. Который правильно указал. Что Паскаль не был последним словом в языковом дизайне.

Помимо того. Что он не соглашался с объединением типов и структур в единое понятие, а также с отсутствием таких конструкций, как условные выражения, оператор возведения в степень и локальные блоки, которые присутствовали в Алголе 60, он упрекал Паскаля за сохранение столь проклятого утверждения go to [Habermann, 1973]. Оглядываясь назад. Нельзя не согласиться: в то время его отсутствие отпугнуло бы слишком многих людей от попыток использовать Паскаль. Смелый шаг по предложению языка без goto был предпринят десять лет спустя преемником Паскаля Modula-2, который исправил многие недостатки и устранил несколько оставшихся уступок совместимости Algol 60, особенно в отношении синтаксиса [Wirth, 1982]. Подробный и взвешенный ответ на критику Хабермана был написан Лекармом. Который судил о достоинствах и недостатках Паскаля как в преподавании. Так и в разработке компилятора [Lecarme, 1975].

Другая значительная критика [Welsh, 1977] обсуждает проблему структурного противопоставления. эквивалентность имен типов данных. Различие, которое. К сожалению. Было оставлено открытым в определении Pascal. Он вызвал много споров. Пока не был решен комитетом по стандартам.

Пожалуй, самой неудачной конструкцией была запись варианта. Он был предоставлен с целью построения неоднородных структур данных. Как для массива. Так и для динамических структур в Pascal типы элементов должны быть зафиксированы объявлениями типов. Запись variant позволяет варьировать типы элементов. К сожалению. Вариант записи Паскаля связан с тем. Что он обеспечивает большую гибкость. Чем требуется для достижения этой законной цели. В динамической структуре. Как правило. Каждый элемент остается того же типа. Что и при его создании. Вариант записи, однако. Позволяет больше. Чем построение гетерогенных структур, т. е. Структур с элементами разных. Хотя и родственных типов.

Он позволяет изменять тип самих элементов в любое время. Эта дополнительная гибкость имеет прискорбное свойство требовать проверки типов во время выполнения для каждого доступа к такой переменной или к одному из ее компонентов. Большинство разработчиков языка Паскаль решили. Что такая проверка будет слишком дорогостоящей. Увеличит объем кода и снизит эффективность программы. Как следствие. Запись вариантов стала излюбленной функцией для взлома системы типов всеми программистами. Влюбленными в трюки. Которые обычно оборачиваются ловушками и катастрофами.

Вариантные записи также стали серьезным препятствием для понятия портабилии программ. Рассмотрим, например. Декларацию

VAR R: RECORD maxspeed: INTEGER; CASE v Vehicle OF truck: (nofwheels: INTEGER); vessel: (homeport: String) END

Здесь обозначение R. nofwheels применимо только в том случае. Если R. v имеет значение truck. А R. homeport-только в том случае. Если R. v = vessel. Никакие проверки компилятора не могут защитить от ошибочного использования обозначений. Что в случае назначения может привести к катастрофическим последствиям. Поскольку средство variant используется реализациями для экономии памяти путем наложения полей nofwheels и homeport.

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

Возможно, и в этом случае предоставление последовательностей любых (даже определенных программистом) типов элементов было больше. Чем действительно требовалось на практике. Следствием этого было то, что. В отличие от всех других типов данных. Файлы требуют определенной поддержки со стороны встроенных подпрограмм времени выполнения. Механизмов. Явно не видимых из текста программы. Преемники Паскаля-Modula-2 и Oberon – позже отошли от представления файла как структурной формы на том же уровне. Что и массив и запись.

Это стало возможным благодаря тому. Что реализация механизмов секвенирования могла осуществляться с помощью модулей (библиотечных пакетов). В Паскале, однако. Понятие модулей еще не существовало; программы на Паскале должны были рассматриваться как единые. Монолитные тексты. Эта точка зрения может быть приемлемой для учебных целей. Где упражнения достаточно компактны. Но она не является приемлемой для построения больших систем. Тем не менее. Как это ни удивительно. Компиляторы Pascal могут быть написаны как отдельные программы Pascal.

Более Поздние События

Поскольку Паскаль, казалось. Оправдывал наши ожидания в отношении преподавания. Компилятор все еще не удовлетворял заявленным целям в отношении эффективности в двух аспектах: во-первых. Компилятор как относительно большая автономная программа приводил к довольно длительному

Чтобы облегчить проблему. Я разработал подмножество языка. Содержащее те функции, которые. Как мы полагали. Должны были быть охвачены во вводных курсах. И пакет компилятора/интерпретатора. Который помещался в блок хранилища 16K-word. Который подпадал под статус наиболее предпочтительной программы вычислительного центра. Пакет Pascal-S был опубликован в отчете и был одной из первых комплексных систем. Широко доступных в исходном виде [Wirth, 1981 ]. Сопоставимые программы на Фортране были все еще значительно быстрее. Что было неоспоримым аргументом в руках противников Паскаля. Поскольку мы придерживались мнения. Что структурированное программирование. Поддерживаемое структурированным языком. И эффективность компиляции и создаваемого кода не обязательно являются взаимоисключающими. Был запущен проект третьего компилятора. Который. С одной стороны. Должен был продемонстрировать преимущество структурированного нисходящего проектирования с пошаговой доработкой [Ammann, 1974]. А с другой-обратить внимание на генерацию высококачественного кода. Этот компилятор был написан У. Амманом и достиг обеих целей весьма превосходно. Она была завершена в 1976 году [Ammann, 1977]. Хотя результатом был сложный компилятор высокого качества и надежности. Оглядываясь назад. Мы должны честно признаться. Что вложенные усилия были несоизмеримы с его эффектом. Он не завоевал многих инженеров и еще меньше физиков. Аргумент о том. Что программы Fortran “работают быстрее* А что дает нам право обучать структурированному. “лучшему” программированию специалистов десятилетней давности? Кроме того, код был сгенерирован для компьютера CDC 6000, который-с его 60-битным словом и супер-RISC – структурой-просто не подходил для этой задачи. Большая часть усилий Амманна была направлена на реализацию атрибутивного набора записей. Хотя с семантической точки зрения это было неуместно. Оно было вызвано соображениями экономии памяти на компьютере с очень длинными словами. Обладание свободой проектирования не только языка. Но и компьютера значительно упростило бы проект. В этом случае распространение Паскаля шло с другого фронта. Вскоре после публикации определения Паскаля мы получили письма. Свидетельствующие об интересе к этому языку и просящие помощи в построении компилятора. Главным образом от людей. Которые не были пользователями компьютеров CDC. Именно этот стимул побудил меня разработать подходящую компьютерную архитектуру. Версия компилятора Аммана – легко выведенная из ранней стадии последовательности уточнений – будет генерировать код для этой “идеальной” архитектуры. Которая была описана в виде программы на языке Паскаль. Представляющей интерпретатор. В 1973 году архитектура стала называться Р-машиной. Код-Р-кодом. А компилятор-Р-компилятором. P—kit состоял из компилятора в P-коде и интерпретатора в виде исходной программы на языке Pascal [Nori, 1981]. Реципиенты могли ограничиться кодированием интерпретатора в своем любимом ассемблерном коде или приступить к модификации исходного кода Р-компилятора и замене его процедур генерации кода. Эта Р-система оказалась ключом к распространению языка Паскаля на многие компьютеры. Но нежелание многих выйти за рамки интерпретирующей схемы также привело к классификации Паскаля как “медленного языка. Ограниченного для использования в обученииСреди получателей Р-комплекта была и команда К. Боулз в Калифорнийском университете в Сан-Диего (UCSD) около 1975 года. Он предвидел. Что компилятор языка Паскаль для интерпретирующей системы вполне может поместиться в памяти микрокомпьютера. И набрался смелости попробовать. Более того, идея P-кода позволила легко портировать Pascal на целое семейство микросхем и обеспечить общую основу для их обучения. Микрокомпьютеры только начали появляться, используя ранние микропроцессоры, такие как Intel 8080, DEC LSI—11 и Rockwell 6502; в Европе они были едва известны в то время. Боулз не только портировал наш компилятор. Его команда построила целую систему вокруг компилятора. Включая редактор программ. Файловую систему и отладчик. Тем самым значительно сократив время. Необходимое для этапа редактирования-компиляции-тестирования. По сравнению с любой другой системой. Используемой в учебном процессе. Начиная с 1978 года. Эта система UCSD-Pascal быстро распространила язык Паскаля среди растущего числа пользователей [Bowles, 1980]. [Clark, 1982]. За год он завоевал больше “друзей Паскаля”. Чем системы. Используемые на больших “главных кадрах”. Завоевали за предыдущее десятилетие. Этот феноменальный успех имел три источника: (1) Язык высокого уровня был доступен на микрокомпьютерах. Которые будут пронизывать образовательные учреждения; (2) Паскаль стал поддерживаться интегрированной системой вместо “автономного” компилятора; и (3), возможно. Самое главное. Паскаль был предложен большому числу компьютерных новичков, т. люди. Не обремененные прежними привычками программирования. Для того, чтобы принять Паскаль. Им не пришлось отказываться от больших предыдущих инвестиций в изучение всех особенностей ассемблерного или фортранского кодирования. Микрокомпьютер сделал программирование общественной деятельностью. До сих пор предназначенной исключительно для высших жрецов вычислительных центров. И Паскаль эффективно победил Фортран на микрокомпьютерах. К 1978 году существовало более 80 различных реализаций Pascal на хостах. Начиная от микропроцессора Intel 8080 и заканчивая суперкомпьютером Cray-1. Но полезность Pascal не ограничивалась учебными заведениями; к 1980 году все четыре крупных производителя рабочих станций (Three Rivers. HP, Apollo. Tektronix) использовали Pascal для системного программирования. Помимо того. Что Р-система была основным средством распространения реализаций языка Паскаль. Она продемонстрировала. Насколько понятными. Переносимыми и надежными могут быть компилятор и системная программа. Многие программисты многому научились у Р-системы. В том числе разработчики. Которые не основывали свою работу на Р-системе, и другие. Которые никогда прежде не могли детально изучить компилятор. Тот факт. Что компилятор был доступен в исходном виде. Привел к тому. Что Р-система стала влиятельным средством внеклассного образования. Несколькими годами ранее были предприняты попытки перенести компилятор Pascal на другие ЭВМ. В этих проектах не использовался интерпретатор или промежуточный код; вместо этого они требовали разработки новых генераторов машинного кода. Первый из этих проектов также оказался самым успешным. Она была предпринята Дж. Уэлшем и К. Куинном из Королевского университета в Белфасте [Welsh, 1972]. Целью был компьютер ICL 1900. Этот проект заслуживает особого упоминания. Потому что его следует рассматривать как одно из самых ранних. По-настоящему успешных начинаний. Которые впоследствии были названы усилиями по разработке программного обеспечения. Поскольку в Белфасте не было компьютера CDC. Цель состояла в том. Чтобы использовать метод. Который требовал как можно меньше работы на машине CDC. То, что оставалось неизбежным. Будет исполнено во время короткого визита в ETH в Цюрихе. Уэлш и Куинн модифицировали компилятор CDC-Pascal. Написанный на языке Pascal. заменяя все операторы. Влияющие на генерацию кода. Кроме того, они написали загрузчик и интерпретатор ICL-архитектуры. Что позволило выполнить некоторые тесты на CDC-компьютере. Все эти компоненты были запрограммированы перед решающим визитом и были завершены без какой — либо возможности тестирования. В Цюрихе программы были составлены. И в течение недели были исправлены некоторые незначительные ошибки. Вернувшись в Белфаст. Сгенерированный код компилятора был исполнен непосредственно ICL-машиной после исправления единственной оставшейся ошибки. Это достижение было достигнуто благодаря очень тщательному программированию и проверке. И оно обосновало заявленные преимущества. Которые могут быть получены при программировании на языке высокого уровня. Таком как Pascal. Который обеспечивает полную статическую проверку типов. Подвиг был еще более примечательным. Потому что больше половины недели пришлось потратить на то. Чтобы найти способ читать программы. Привезенные из Белфаста. Зная о несовместимости наборов символов и форматов кассет двух машин (7 — и 9-трековые кассеты). Уэлш и Куинн решили использовать перфокарты в качестве носителя данных. Однако встреченные препятствия, вероятно. Были не менее грозными. Считывание карт. Пробитых машиной ICL с помощью считывателя CDC. Оказалось сложной. Если не совсем невыполнимой задачей. Машины не только использовали различные наборы символов и различные кодировки. Но и некоторые комбинации отверстий интерпретировались непосредственно читателем как конец записей. Производители сделали все возможное. Чтобы обеспечить несовместимость! Кроме этих опасностей. Путешественники не учли тщательности швейцарских таможенников. Две коробки. Заполненные примерно четырьмя тысячами карточек. Несомненно. Должны были вызвать у них глубокое подозрение. Особенно потому. Что эти карточки содержали пустые ячейки. Неравномерно расположенные через пробитые отверстия. Тем не менее. После заверений в том. Что эти ценные вещи в любом случае будут реэкспортированы. Двум потенциальным контрабандистам было разрешено приступить к выполнению своей миссии. По их возвращении тот факт. Что теперь отверстия были расположены по-другому, к счастью. Остался незамеченным. Последовали и другие попытки портировать компилятор; среди них были компьютеры IBM 360 в Гренобле, PDP-11 в Твенте [Bron, 1976] и PDP-10 в Гамбурге (Grosse-Lindemann, 1976). К 1973 году Паскаль стал более широко известен и использовался в классах. А также для небольших программных проектов. Существенным условием для такого принятия было наличие руководства пользователя. Включающего учебные материалы в дополнение к определению языка. Кэти Дженсен приступила к подготовке обучающей части. И к 1973 году брошюра была опубликована издательством Springer-Verlag. Сначала в серии лекционных заметок. А после слишком быстрого распространения-как самостоятельный выпуск [Jensen, 1974]. Вскоре она должна была сопровождаться растущим числом вводных учебников от авторов из многих стран. Само Руководство пользователя впоследствии было переведено на множество различных языков и стало бестселлером. В вычислительном центре Университета Миннесоты была создана специальная группа поклонников Паскаля. Под руководством и с энтузиазмом Энди Микеля была сформирована Группа пользователей Pascal (PUG). Средством коммуникации которой стал Информационный бюллетень Pascal. Сначала издававшийся Г. Х. Ричмондом (U. of Colorado). А затем Mlckel. Первый номер вышел в январе 1974 года. Он служил в качестве доски объявлений для новых реализаций Pascal. Нового опыта и – конечно – идей по улучшению и расширению языка. Его самый важный вклад состоял в отслеживании всех новых реализаций. Это помогло как потребителям найти компиляторы для своих компьютеров. Так и разработчикам скоординировать свои усилия. В ETH Zurich мы решили перейти к другим проектам и прекратить распространение компилятора. А Миннесотская группа была готова взять на себя его обслуживание и распространение. Техническое обслуживание здесь относится к адаптации к постоянно меняющимся версиям операционной системы. А также к появлению стандарта Pascal. Примерно в 1977 году был создан комитет по определению стандарта. На Саутгемптонской конференции по Паскалю А. М. Аддиман обратился за помощью в формировании комитета по стандартам при Британском институте стандартов (BSI). В 1978 году представители промышленности встретились на конференции в Сан-Диего. Организованной К. Боулз. Чтобы определить ряд расширений для Pascal. Это ускорило формирование комитета по стандартам под крылом IEEE и ANSI/X3. Формирование Рабочей группы в рамках ИСО последовало в конце 1979 года. И, наконец. Комитеты IEEE и ANSI/X3 были объединены в единый совместный комитет Pascal. Значительные конфликты возникли между комитетом США и комитетами Великобритании и ИСО. В частности. По вопросу соответствия параметров массива (динамических массивов). Последнее стало главным отличием оригинального Pascal от принятого ISO. Другим стало требование полных спецификаций параметров для параметрических процедур и функций. Конфликт по вопросу динамических массивов в конечном итоге привел к различию между стандартами. Принятыми ANSI. С одной стороны. И BSI и ISO-с другой. Нерасширенный стандарт был принят IEEE в 1981 году и ANSI в 1982 году [Cooper, 1983]. [Ledgard, 1984]. Отличающийся стандарт был опубликован BSI в 1982 году и одобрен ISO в 1983 году [ISO, 1983]. [Jensen, 1991]. В то же время несколько компаний внедрили Pascal и добавили свои собственные. Предположительно неоправданные расширения. Стандарт состоял в том. Чтобы вернуть их под один зонтик. Если бы у кого-то и был шанс воплотить эту мечту в реальность. То это были бы быстрые действия по объявлению языка оригинала стандартом, возможно. С добавлением нескольких разъяснений относительно неясных моментов. Вместо этого несколько членов группы пали жертвой дьявольских искушений: они расширили язык своими любимыми чертами. Большинство из этих функций я уже рассматривал в оригинальном дизайне. Но отбросил из-за трудностей в четком определении или эффективной реализации. Или из-за сомнительной выгоды для программиста [Wirth, 1975]. В результате начались долгие дебаты. Потребовавшие многих встреч. Когда комитет наконец представил документ. Язык уже почти вернулся к первоначальному паскалю. Однако со времени публикации доклада прошло десять лет. В течение которых отдельные лица и компании производили и распространяли компиляторы. И они не стремились модифицировать их. Чтобы соответствовать последнему Стандарту. И еще меньше стремились отказаться от своих собственных расширений. Реализация Стандарта была позже опубликована в [Welsh, 1986]. Однако еще до публикации Стандарта был создан набор программ валидации. Который сыграл значительную роль в обеспечении совместимости между различными реализациями [Wichmann, 1983]. Его роль даже возросла после принятия Стандарта. И в США он сделал возможным Федеральный стандарт обработки информации для Pascal. Начало 70-х годов было временем. Когда после впечатляющих провалов крупных проектов появились такие термины. Как Структурированное программирование и Программная инженерия. Они действовали как символы надежды для утопающих. И слишком часто считались панацеей от всех бед прошлого. Эта тенденция еще больше подняла интерес к Паскалю. Который – в конце концов – демонстрировал ясную структуру и находился под сильным влиянием Э. Учение Дейкстры о структурированном дизайне. 70-е годы были также годами. Когда в том же духе считалось. Что формальная разработка доказательств правильности программ была конечной целью. АВТОМОБИЛЬ. Хоар постулировал аксиомы и правила вывода о программировании обозначений (позже это стало известно как Хоар-логика). Он и я взяли на себя задачу формально определить семантику Паскаля. Используя эту логику. Однако мы должны были признать. Что ряд признаков должен был быть опущен из формального определения (например. Указатели) [Хоар, 1973]. Паскаль therafter служил средством для реализации валидаторов программ по крайней мере в двух местах. А именно в Стэнфордском университете и ETH Zurich. E. Marmier расширил компилятор. Чтобы принимать утверждения (в форме отмеченных комментариев) отношений между переменными программы. Содержащимися после (или до) исполняемых операторов. Задача проверки утверждений состояла в проверке или опровержении непротиворечивости утверждений и утверждений в соответствии с логикой Хоара [Marmier, 1975]. Его работа была одной из первых в этом направлении. Хотя он смог установить правильность для различных достаточно простых программ. Его основной вклад состоял в том. Чтобы развеять простодушную веру в то. Что все может быть автоматизировано. Паскаль оказал сильное влияние на область языкового дизайна. Он действовал как катализатор для новых идей и как средство для экспериментов с ними. И в этом качестве дал начало нескольким языкам-преемникам. Возможно, первым был параллельный Паскаль П. Бринча Хансена [Brinch Hansen, 1975]. Он включил понятия параллельных процессов и примитивов синхронизации в последовательный язык Pascal. Аналогичная цель. Но с акцентом на моделирование дискретных систем событий на основе (квази) параллельных процессов. Привела к Pascal-Plus. Разработанному J. Welsh и J. Elder в Белфасте [Welsh, 1984). Значительно больший язык стал результатом амбициозного проекта Lampson et.al. Целью которой было покрыть все потребности современной. Крупномасштабной программной инженерии. Хотя и отклоняющийся во многих деталях. А также в синтаксисе. Этот язык Mesa имел Паскаль в качестве предка [Mitchell, 1978]. Он добавил революционную концепцию модулей с отношениями импорта и экспорта. То есть скрытия информации. Его компилятор ввел понятие отдельной – в отличие от независимой – компиляции модулей или пакетов. Эта идея была принята позже в Modula-2 [Wirth, 1982], языке. Который в отличие от Mesa сохранил принципы простоты. Экономии понятий и компактности. Которые привели Паскаля к успеху. Другой производной от языка Паскаля является язык Евклида [London, 1978]. Определение его семантики основано на формализме. Точно так же. Как синтаксис Алгола 60 был определен формализмом BNF. Евклид тщательно опускает черты. Которые формально не поддаются определению. Object Pascal-это расширение языка Pascal. Включающее понятие объектно-ориентированного программирования. То есть абстрактного типа данных. Связывающего данные и операторы вместе [Tesler, 1985]. И последнее. Но не менее важное. Следует упомянуть язык Ada [Barnes, 1980]. Его дизайн был начат в 1977 году и явно находился под влиянием Паскаля. Однако ей не хватало экономии конструкции. Без которой определения становятся громоздкими. А реализации-чудовищными.

Оглядываясь

назад. Я был вдохновлен изложить свою оценку достоинств и слабостей Паскаля. Ошибочных решений в его разработке. А также его перспектив и места в будущем. Я предпочитаю не делать этого явно и вместо этого отсылаю читателя к моим собственным последовательным разработкам-языкам Modula-2 [Wirth, 1982] и Oberon [Wirth, 1988]. Если бы я назвал их Паскаль-2 и Паскаль-3, то вопросов, возможно. Не возникло бы. Потому что эволюционная линия этих языков была бы очевидна. Также бесполезно подвергать сомнению и обсуждать ранние проектные решения; лучшие решения часто совершенно очевидны задним числом. Возможно. Самым важным моментом было то. Что кто-то действительно принимал решения. Несмотря на неопределенность. В принципе, принцип включения функций. Которые были хорошо поняты. В частности. Разработчиками. И исключения тех. Которые все еще не были опробованы и не реализованы. Оказался наиболее успешным единственным руководством. Второй важный принцип заключался в публикации определения языка после того. Как была установлена полная реализация. Публикация проделанной работы всегда более ценна. Чем публикация запланированной. Хотя Паскаль не пользовался поддержкой промышленности. Профессиональных сообществ или правительственных учреждений. Он стал широко использоваться. Важной причиной этого успеха было то. Что многие люди. Способные распознать его потенциал. Активно занимались его продвижением. Наличие документации так же важно. Как и наличие хороших реализаций. Лаконичность первоначального доклада сделала его привлекательным для многих учителей. Чтобы расширить его в ценные учебники. Бесчисленные книги появились на многих языках в период с 1977 по 1985 год. Эффективно продвигая Паскаль. Чтобы стать самым распространенным языком. Используемым в вводных курсах программирования. Хорошие учебные материалы и их реализация являются необходимыми предпосылками для такой эволюции. На момент написания этой книги Паскаль все еще широко использовался в преподавании. Может показаться. Что он подвергается той же участи. Что и Фортран. Стоящий на пути прогресса. Более благожелательный взгляд отводит Паскалю роль прокладывающего путь для преемников.

Признание

Я от всей души благодарю многих авторов. Чья работа сыграла незаменимую роль в успехе усилий Паскаля и которые тем самым прямо или косвенно помогли продвинуть дисциплину проектирования программ. Особое спасибо МАШИНЕ. Хоара за предоставление многих просвещающих идей. Которые текли в дизайн Паскаля, U. Ammann. E. Marmier и R. Schild за их доблестные усилия по созданию эффективного и надежного компилятора. A. Mickel и его команда за их энтузиазм и неустанное участие в том. Чтобы сделать Паскаль широко известным. Создав пользовательский Круп и Информационный бюллетень. И К. Боулз за признание того. Что наш компилятор Pascal также был пригоден для микрокомпьютеров и для действия на этом озарении. Я также благодарю бесчисленных авторов учебников. Без вводных текстов которых Паскаль не мог бы получить того признания. Которое он получил.

Ссылки

[Ammann, 1974]
Ammann. U.д структурированного программирования. Применяемый к разработке компилятора. Международный вычислительный симпозиум 1973. 93 – 99, Северная Голландия, 1974.

[Ammann, 1977]
Ammann. U.ode Generation in a Pascal Compiler. Программное обеспечение – Практика и опыт, 7, 391-423 (1977).

[Barnes, 1980]
Обзор Ады. Программное обеспечение – Практика и опыт, 70, 851 – 887 (1980).

[Bowles, 1980]
Bowles. Kешение задач с использованием Pascal. Springer-Verlag, 1977.

[Brinch Hansen, 1975]
Brinch Hansen. P. Программирования Параллельный Pascal. IEEE Trans. Программное обеспечение 1,2,199 – 207, (1975).

[Bron, 1976]
8ron. CW. de Vries. Компилятор Pascal для миникомпьютеров PDP-11. Программное обеспечение – Практика и опыт. 6,109-116 (1976).

[Clark, 1982]
Clark. R.S. Koehler. The UCSD Pascal Handbook. Прентис-Холл, 1982.

[Cooper, 1983]
Cooper. D.dard Pascal. Руководство Пользователя. Нортон, 1983.

[Dijkstra. 1966)
Dijkstra. E. W., Structured Programming. Технологии. Отчет, Univ. of Eindhoven, 1966. также в: Dahl, O. – J. et al. Structured Programming, London: Academic Press 1972.

[Grosse-Lindmann, 1976]
Grosse-Lindemann, C. O.. And H. H. Nagel. Postlude to a Pascal-Compiler Bootstrap on a DECsystem-10. Программное обеспечение – Практика и опыт, 6. 29-42, (1976).

[Habermann, 1973]
Habermann, A. N., Critical comments on the programming language Pascal, Ada Informatics 3,47 – 57 (1973).
[Hoare, 1972]
Hoare, CAR.. Notes on Data Structuring.
In: Dahl, O. -J. et al. Structured Programming, London: Academic Press 1972.

[Хоар, 1973]
Хоар. АВТОМОБИЛЬ. и Н. Вирт. Аксиоматическое определение языка программирования Pascal. Acta Informatics 2,335 – 355 (1973)

[Хоар. 1980]
Хоар. МАШИНА… Старая Одежда Императора. Комм.ACM, 24, 2 (февраль 1980). 75 – 83 (февраль 1980).

[ISO, 1983]
Международная организация по стандартизации. Спецификация для языка компьютерного программирования Pascal. ISO 7185-1982.

[Jensen, 1974]
Jensen. K. and N. Wirth. Pascal — User Manual and Report. Springer-Verlag, 1974.

[Jensen, 1991]
Jensen. K. N. Wirth. Пересмотрено A. B. Mickel и J. F. Miner, Pascal. Руководство пользователя и отчет. Стандарт ISO Pascal. Springer-Verlag, 1991.

[Lecarme, 1975]
Lecarme, 0. and P. Desjardlns. More comment] on the programming language Pascal. Ala Informatics 4. 231 – 243 (1975)

[Ledgard.1984]
Ledgard. H. Американский стандарт Паскаля. Springer-Verlag, 1984.

[Лондон, 1978]
London, R. L, J. V. Guttag, J. J. Homing, 8. W. Lampson. J. G. Mitchell и G. J. Popek. Правила доказательства для языка программирования Евклид. Ada Informatics 10,1 – 26 (1978).

[Мармье, 1975]
Э. Мармье. Автоматическая верификация программ на языке Pascal. ETH-Диссертация № 5629, Цюрих, 1975

[Mitchell, 1978]
Mitchell. J. C W. Maybury. R. Sweet Mesa Language Manual. Отчет Xerox PARC Report CSL-78-1 (1978).

[Naur, 1963]
Naur. P.) Пересмотренный отчет по алгоритмическому языку Algol 60, Комм. ACM 3, 299 – 316 (1960) и Comm. АСМ 6,1 – 17 (1963)

[Nori, 1981]
Nori. K. V., et al.. The Pascal P-code compiler: Implementation notes.
В: D. W. Barron, ed.. Pascal – Язык и его реализация. Уайли 1981.

[Tesler, 1985]
Tesler. Lct Pascal Report.
Structured Programming (ранее Structured Language World), 9, 3, (1985), 10-14.

[van Wijngaarden, 1969]
van Wijngaarden. A., (ред.). Доклад об алгоритмическом языке Algol 68. Numer. Математика. 14, 79 – 218 (1969)

[Welsh, 1972]
Welsh. J.C. Quinn. Компилятор Pascal для компьютеров серии ICL1900. Программное обеспечение. Практика и опыт 2. 73-77 (1972).

[Welsh, 1977] Welsh. J., W. J. Sneeringer и CAR. Хоар, Двусмысленность и Неуверенность в
программном обеспечении Pascal. Практика и опыт, 7, (1977), 685 – 696.
Также в: D. W. Barron. ed.. Pascal — The language and its implementation. — спросил Уайли.

[Welsh, 1984] Welsh. J.D. Bustard. Sequential Program Structures. Prentice-Hall Int’l, 1984.

[Welsh, 1986] Welsh. J.A Hay. A Model Implementation of Standard Pascal. Прентис-Холл Интл, 1986.

[Wichmann, 1983]
Wichmann. B.Ciechanowicz. Pascal Compiler Validation. Уайли, 1983.

[Wirth, 1966]
Wirth, N. и CAR. Хоаре, Вклад в развитие АЛГОЛА, Комм. ACM 9,6,413 – 432 (июнь 1966)

[Wirth, 1970]
Wirth, N.. The Programming Language Pascal, Tech. Rep. 1, Fachgruppe Computer-Wissenschaften, ETH, Nov. 1970, andAda Informatics 1.35 – 63 (1971)

[Вирт, 1971а]
Вирт. Н. Разработка программы путем поэтапного уточнения. Связь. ACM 14, 4,221 -227 (апрель 1971)

[Wirth, 1971b]
Wirth. N.design of a Pascal compiler. Программное обеспечение. Практика и опыт 1,309 – 333 (1971).

[Вирт, 1975]
Вирт. Н.Оценка языка программирования Pascal. Лиитранс. on Software Eng.. 1. 2 (июнь 1975), 192 -198.

[Wirth, 1981]
Wirth. N. Pascal-S: подмножество и его реализация. В: D. W. Barron, ed.. Pascal – Язык и его реализация. Уайли 1981.

[Wirth, 1982]
Wirth. N.ramming in Modula-2. Springer-Verlag, 1982.

[Wirth, 1988]
Wirth. N.Programming Language Oberon. Программное обеспечение. Практика и опыт 18,7 (июль 1988), 671 – 690.