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

Ну а Вирт, как обычно, ответил не словами, а делами -- Modula-2 был убедительным ответом на вопрос, каким должен был быть в его представлении надежный язык для ответственных крупных военных проектов.

Так значит Вирт с Модулой не успел... :(
Эх, какой язык загубили...

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

Как известно, первый препринт ETH Zurich по классическому Паскалю появился в ноябре 1970 г. Кстати, он и вышел среди прочих технических отчетов ETH за номером 1, что весьма знаменательно. Два года назад я попросил Вирта помочь его получить, но в Москве Вирт извинялся, что просьбу выполнить не удалось, и при этом выглядел несколько озадаченным. Оказалось, что в его архивах и ближайшем доступном окружении этого препринта не было. Потом его где-то раздобыли, отсканировали и выложили среди других препринтов ETH (правда, все-таки во второй редакции -- июля 1971 г.). Он доступен и на EuroProg: http://www.europrog.ru/paper/nw1970-01e.pdf

К тому моменту уже существовала система программирования Паскаля на компьютере CDC 6000 (фирмы Control Data Corp.). Вирт вообще старался придерживаться золотого инженерного правила: сначала реализовать идеи, прочувствовать их физический смысл на практике, а только потом "столбить". Компилятор (причем однопроходный) на CDC 6000 был написан на самом Паскале и реализован методом раскрутки (bootstrapping), что уже обсуждалось. Это отмечено и в препринте.

Дальше будет интересно: не поленитесь открыть этот препринт. И вы поймете, зачем я его искал (не только ради исторического интереса). На стр. 21 в пунке 6.2.5 там найдете... классы (class types), реализованные в соответствии с идеями Тони Хоара. Напомню, что, на мой взгляд, первый программный манифест ООП был озвучен Тони Хоаром в 1966 г. на Летней школе научного комитета NATO, которая прошла в Виллар-де-Ланс (Франция). Там же был Оле-Йохан Дал, который использовал выступление Хоара (и две предшествовавшие этому публикации Хоара по обработке записей) для пересмотра своей Симулы (вместе с Нигаардом).

Хоар обобщил опыт первой Симулы и ряда других языков (включая PL/I) и в докладе "Record Handling" в Виллар-де-Ланс изложил идею record class (что в несколько видоизмененном виде и под названием class вошло в Симулу-67). Я об этом здесь уже как-то упоминал. При этом идеи записей и их взаимосвязь со ссылками на практическом уровне детально были разобраны еще в первом языке Вирта -- Euler (1965), которым так интересовался Алан Кей (автор Smalltalk). А схема Хоара (record class) была реализована до Паскаля в виртовском языке "Algol W": см. http://www.europrog.ru/paper/nw1966-03e.pdf и http://www.europrog.ru/paper/nw_algw.pdf

Сами же записи (record) впервые появились в языке AED-0 Дугласа Росса (кстати, основателя той самой компании SofTech, которая вошла в число 4 финалистов Ада-тендера). Он же был автором известных методологий SADT и IDEF0. Стоит вспомнить, что в начале 1970-х годов Дуглас Росс утверждал, что "80% или даже 90% информатики будет в будущем основываться на теории конечных автоматов". В AED-0 записи назывались шариками, каплями (beads). Использовалось и понятие plex (узел), которое обозначало группу записей, связанных с помощью ссылок.

Итак, Вирт в Паскале практически лоб в лоб реализовал идеи своего друга и коллеги (вот, кстати, откуда пошли вариантные записи -- от Хоара), хотя наследование (subclass) Вирта явно насторожило. Эта конструкция первого Паскаля (class type), как следует из более известного препринта ETH по пересмотренному Паскалю (ноябрь 1972 г.), из языка спустя год с небольшим была изъята (а заодно Вирт powerset переименовал в set плюс добавил упакованные записи): http://www.europrog.ru/book/panw1972e.pdf

Вирт посчитал, что просто record с указателями будет вполне достаточно и специальное слово class с дополнительной семантикой лучше не вводить. Спустя полтора десятилетия (примерно в 1986 г.) Вирт вернулся в одном из первых внутренних вариантов Оберона к корням ООП в трактовке Хоара, дополнив ее с подачи Юрга Гуткнехта конструкцией расширения типа (type extension). При этом оказался верен своему предубеждению против ООП.

В 1972 г., кстати, был опубликован второй манифест ООП: "Иерархические структуры программ" (Hierarchical Program Structures), авторами которого были Оле-Йохан Дал и Тони Хоар. Это был печатный вариант лекций Дала в Летней школе в Маркторбердорфе (Германия) в 1970 г. Его перевод на русский язык можно найти в сборнике "Структурное программирование": http://www.europrog.ru/book/spod1975r.pdf
Там же был представлен механизм композиции классов, который получил название сочленения.

Как вспоминает Пер Бринч Хансен, весной 1972 г. он прочел упомянутую работу Дала и Хоара и пришел к выводу, что если раньше он мыслил монитор (в понимании, разумеется не экрана, а концепции мультипрограммирования) как программный модуль, который определяет все операции в одном экземпляре структуры данных. То теперь у Хансена было восприятие модуля как описания класса структур данных, доступных через те же самые процедуры. Обратите внимание, класса, а не экземпляра. "Для меня то был момент истины", -- пишет Хансен в работе "Monitors and Concurrent Pascal" (это было одновременно и его выступление на Конференции ACM по истории языков программирования HOPL-II в апреле 1993 г.).

Вот где, на мой взгляд, проходит водораздел в восприятии модулей и близких к ним вещей (классы). У Вирта модуль -- это принципиально экземпляр. Причем готовый полуфабрикат для превращения модуля в монитор (т.е. как средства не только управления видимостью и "контейнеризации", но и регулирования конкурентного доступа к разделяемым ресурсам)! Стоит вспомнить откуда пошло название: монитором в 1960-х годах называлась резидентная часть ОС.

В 1973 г.  Пер Бринч Хансен излагает свои идеи мультипрограммирования с помощью мониторов в книге “Принципы операционных систем” (Operating System Principles). Язык Concurrent Pascal и ОС Solo стали практическим результатом его исследований. Целью Бринч Хансена, по его собственному признанию,  было добиться в сфере ОС того, чего добился Паскаль в отношении разработки компиляторов. Вот отсюда и берут свои истоки многие идеи "растворения" языка программирования и поддерживающей его системы программирования в ОС: а в контексте Паскаль-линии это UCSD Pascal и Oberon/КП.

Ответ на »сообщение 3467« (Geniepro)
___________________________

Вот почему это так опасно и лучше так не делать... :о)

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

Осталось только придумать, как реализовать динамическое расширение функциональности в чистом функциональном виде...

А Вы никогда не задумывались, зачем нужна эта пресловутая чистота? В ФП чистота мнимая (давайте не будем убеждать себя и других, что это не так). Так зачем пытаться прикрутить красивый элегантный дирижабль ФП к велосипеду ИП? Рожденный летать, ползать не может :) Может лучше -- каждому то, что у него лучше получается?

Ответ на »сообщение 3468« (Geniepro)
___________________________

Переход - надо полагать, goto?

Не только, goto -- это частный случай. Цикл и ветвление -- все это переходы (безусловные и условные). Из ассемблера Вы наверняка должны это хорошо знать. В императивном программировании существует два различных вида операторов: assignment statement (присваивание) и branching statement (переход).

Вообще-то это подробно разбирается в упомянутых работах. Присваивание бывает непосредственное и косвенное (через указатель). Переход -- безусловный (простой, simple; это и есть goto, в том числе на нижнем уровне), и условный (ветвление, if Expression then goto Label).

А почему Вирт остановился на отбрасывании goto и не отошошёл от множественного присваивания?

В goto нет никакой необходимости. Вопрос первым поднял, если не ошибаюсь, Петер Наур (хотя большинству известна только более поздняя работа Эдсгера Дейкстры). В классическом Паскале оператор goto (с меткой) использовался. В языке Modula-2 он был за ненадобностью изъят. На самом деле в той же Modula-2 был введен и "косвенный" goto (без метки) -- это оператор EXIT для безусловного цикла LOOP. В паре с оператором RETURN он и стал равноценной и надежной заменой goto.

Что касается множественного присваивания (сразу нескольких значений), то Вирт от него вроде бы и не отказывался. Он просто его никогда и не использовал. Для него всегда readability (наглядность, удобство анализа) было более важно, чем writeability (компактность кодирования, удобство синтеза). Именно это важное свойство языка было заложено в основу требований Мин.обороны США в 1975 г., когда начался тендер по созданию Ады. Военные системы должны быть долгоживущими, активно сопровождаемыми и допускающими легкость внесения изменений в чужой код. Массовому же рынку долгоживучесть и сопровождаемость по барабану. Ну а системщиков всегда привлекала "шифруемость" и изощренность синтаксиса, поскольку это приближало их к касте избранных. Что же мы удивляемся наплевательскому отношению к синтаксису со стороны разработчиков нынешних языков (особенно скриптовых)? Главное по-быстрому закодить и показать уровень своей виртуозности. А дальше -- трава не расти.

Именно в силу огромной важности clarity (ясности) и readability варианты на основе языков APL и Си (самыми тогда модерновыми) были отвергнуты без толики сомнения. Помимо APL и Си в борьбе за победу в Ада-тендере были Кобол, Фортран, PL/I, Алгол-60, Алгол-68, Симула-67, JOVIAL, CORAL 66, EUCLID и многие-многие другие.

Но в четверку лучших (из которых и пошел дальнейший отбор победителя) вошли предложения только на основе Паскаля. Ззагадочной любовью американцев к европейскому языку да еще с прицелом на тотальное использование в проектах Минобороны США это конечно объяснить нельзя, равно как и ложными утверждениями о том, что тендерные предложения можно было подавать только на Паскале. Из четырех вариантов, прошедших первое сито отбора, были работы на Паскале от компаний: CII-Honeywell Bull, Intermetrics, SofTech и SRI-International. Ну а к победе в итоге пришла вообще европейская компания (CII-Honeywell Bull, Франция), что по тем временам казалось просто немыслимым. Надо сказать, что к консультированию были привлечены Дейкстра, Хоар, Вирт (причем на финансовой основе -- по линии бюджета Военно-морских сил Великобритании). Однако их мнение, как потом выяснилось, было практически проигнорировано (как и в деятельности по Алголу-68). В своей речи при вручении премии Тьюринга ("Старые платья императора") Тони Хоар в 1980 г. высказал все, что думает по поводу получившейся Ады (ничего хорошего). А Дейкстра? Как вспоминал А.П.Ершов, принимая его у себя в Голландии, затворник Дейкстра обронил фразу в духе того, что Советскому Союзу очень повезло, что он не использует Аду в военных проектах. Ну а Вирт, как обычно, ответил не словами, а делами -- Modula-2 был убедительным ответом на вопрос, каким должен был быть в его представлении надежный язык для ответственных крупных военных проектов. В представлении того, кто и был автором базисного языка (Паскаля), одержавшего оглушительную победу в тендере Минобороны США.

Вообще-то при анализе эволюции языков очень важно не забывать о периоде 1975-1980 гг., наложившем отпечаток на работу многих ученых и исследователей. Именно в эти годы был затеян грандиозный шум вокруг будущей Ады. Это был, пожалуй, самый яркий в мировой истории открытый проект по созданию языка лучшими умами мира. Именно тогда мультипрограммирование, модульное программирование и вопросы надежности были поставлены во главу угла. Сейчас об этом как-то стали подзабывать, если не сказать жестче.

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

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

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

Ответ на »сообщение 3466« (Илья Ермаков)
___________________________

Здравствуйте. Прошу прощения за оффтопик.
Я потерял свой пароль от Вашего форума.
Можете подсказать, как в StdTables.Table

1. Закрашивать фон отдельно выбранных ячеек ?
2. Автоматически регулировать ширину столбца по длине
  самого длинного текста ?

С уважением,

Ответ на »сообщение 3466« (Илья Ермаков)
___________________________

А если сервис не так прост, чтобы A мог его самостоятельно предоставить?

Это решается и без всякой "инверсии" экспорта - стандартными механизмами - задача разбивается на подзадачи и только А знает, какие модули эти подзадачи решают...
Делегаты, конечно, могут быть удобны, но всё-таки это опасно...


Например, все модули BlackBox Framework - а значит и пользовательские модули - не потребуют перекомпиляции под Линукс, потому что в них нет ни платформенно-зависимого кода, ни импорта платформенно-зависимых модулей. Вся "платформа" - в лежащей сбоку и никем не импортируемой подсистеме Host.

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

Тут воэникает такая тонкая грань между гибкостью и надёжностью... А о формальной корректности даже и речи быть не может, имхо...

Ответ на »сообщение 3464« (Руслан Богатырев)
___________________________

Как отмечал Вирт еще в середине 1960-х годов, когда особенно плотно занимался лямбда-исчислением и применимостью ФП для задач обобщения императивных конструкций, для ФП чужеродны две ключевых вещи императивного программирования: присваивание и переход.

Переход - надо полагать, goto?
А почему Вирт остановился на отбрасывании goto и не отошошёл от множественного присваивания?

Ответ на »сообщение 3465« (AVC)
___________________________

Как, например, гарантировать, что импортируемая функция sin не возвращает значение другой функции, скажем cos? Ведь формально этому ничего не мешает.

Ну как так не мешает?
Если я импортирую функцию sin из модуля Math, то я вправе ожидать, что эта функция делает именно то, что для неё заявлено - ведь это гарантирует известный мне поставщик модуля Math.
А если возможны такие перехваты поведения функций всякими неизвестными товарищами - то таких гарантий никто дать не в состоянии. Вот почему это так опасно и лучше так не делать... :о)

Осталось только придумать, как реализовать динамическое расширение функциональности в чистом функциональном виде... Может даже премию Тьюринга дадут... :о))
Эх, надо всё таки заняться этими стрелами из Хаскелла - может они смогут дать что-то подобное...