К интерпретатору интерпретаторов

1. Два базовых феномена в конструкции машины - состояния элементов памяти и операции с ними. Программа - синтез, комбинация этих двух феноменов, символьная структура, идентифицирующая процесс интерпретации как серию инструкций с инвариантами (константами).
2. Следующий этап развития символизации - переход к параметризация состояний элементов памяти, атрибуции состояний, абстракция вариативности, серии состояний, именование блоков, включая динамику их размера, что обусловливает организацию параллельных процессов, конкурирующих за ресурсы, асинхронной интерпретации.
3. Графический интерфейс вывел проектирование на следующий уровень приложений, явную демонстрацию символьных вычислений для проектирования и моделирования любых процессов, включая физические, химические, биологические и социальные.
4. Программы как и тексты - пассивные конструкции, отличающиеся от активных компьютеров, изменяющих свое состояние, интерпретирующих (генерирующих и трансформирующих) код.
5. Система категорий как основания информатики:

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

Обращение к объекту может изменить состояние только этого объекта - принцип информационной замкнутости – обобщает опыт борьбы с «побочными эффектами». Понятие замкнутости проявляется в программирования в различных ситуациях – так, например, программный фрагмент замкнут по управлению, а операционная обстановка по исполнению. Только к объектам и протоколам, указанным в перечнях обстановки, могут происходить обращения при единичном исполнении программного фрагмента. При этом у разных обстановок могут быть совсем разные исполнители, а исходные тексты программных фрагментов могут быть выражены на различных языках. Однако программный фрагмент всегда составлен из предписаний, каждое из которых может рассматриваться как вызов реализующего его программного фрагмента, исполняемого в своей подходящей операционной обстановке. 

Четыре вида "предписаний": структурные – изменяющие порядок исполнения по сравнению с линейным порядком записи предписаний в программном фрагменте; команды исполнителя, которые он «сам знает, как исполнить»; обращение к объектам, предусмотренным в перечне в обстановке; обращение к протоколам организации взаимодействия с объектами.

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

Доступы суть значения (состояния), а поскольку работа с ними требует предосторожности, то для этого должны быть выделены особого типа объекты, которые можно называть держателями доступа.

Логическое строение объекта может быть представлено в следующем виде: домен хранит состояние и отвечает за уникальность объекта, в то время как программные фрагменты – методы и интерфейс – определяют тип объекта и его отнесение к соответствующим классам; при этом тип однозначно определён набором методов. Разумеется, исполнение методов при обращении к объектам происходит в подходящих отдельных операционных обстановках, и, следовательно, они могут разрабатываться на адекватных каждому случаю языках.

При создании объекта создаётся его домен, и подключаются все методы, выводимые из наследственных соотношений между классами и полиморфизма обращений. Другими словами, это означает, что информация, относящаяся к описыванию наследования, вообще должна «срабатываться» при трансляции и не доходить до фазы исполнения. Само отношение наследования не применимо к объектам.

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

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

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

Понятие конфигурации оказывается полезным и гибким во многих случаях, а не только при описании совокупности подобъектов составного объекта. Например, все конструкции с переменным составом элементов оказываются на самом деле конфигурациями Входящие в конфигурацию объекты продолжают оставаться объектами своих подпространств. Если все элементы конфигурации входят только в неё, то работа с ней практически не отличается от работы с составным объектом. Однако если некоторый объект входит сразу в разные конфигурации, то ситуация сильно усложняется, поскольку каждая из них может и не знать о существовании другой, но обнаружить, что какой-то из её объектов «вдруг самостоятельно» изменил своё состояние. Такая наведённая активность на самом деле является существом работы портов ввода-вывода. Тот факт, что с конфигурациями приходится работать отличными от составных объектов способами, и является основанием для введения этого конструкта. 

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

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

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

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

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

Всё предыдущее изложение касалось конструкций и свойств, необходимых для хорошей организации исполнения программ. Однако из вышеизложенного также должно быть ясным, что я рассматриваю программы как тексты. Более того, как очень сложные текстовые комплексы, возможно, составленные из фрагментов, принадлежащих разным языкам, с богатой структурой связей, но обязательно исполняемые и тем самым имеющие смысл, ибо смысл программы (как и музыки) состоит в том, что она исполняется. 

Проектирование сложных программ оказало существенное влияние на создание систем электронной подготовки изданий, разумеется, весьма полезных и для общей полиграфии и развития типографики. Оно включало и проектирование шрифтов, смыкаясь в определённой степени с изобразительным искусством. И, vice versa, богатые возможности полиграфии позволяют публиковать сложные программные системы удобочитаемым и наглядным образом – здесь неоценим опыт и пример Дональда Кнута. 

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

Но и для программ всё обстоит так же: действительно, с единичным исполнением программного отрезка в операционной обстановке можно сопоставить историю исполнения, в которую выписываются все исполненные предписания. Конечно история – это текст, но она задаёт последовательность предписаний, и, если подать её в тождественную операционную обстановку, то история исполнения истории будет совпадать с ней самой. 

Однако вполне может оказаться, что предъявляемый для исполнения программный фрагмент сможет быть исполнен (а значит – понят) и в некоторой другой обстановке, а значит, будет иметь смысл и в ней. Только смысл может быть будет другой: «всякая обстановка создаёт при исполнении смысл в меру своего наполнения». 

Вот и сейчас: я прочел доклад, а каков его смысл, каждый слушавший придумал сам. А вы говорите: «интеллектуальная собственность» …

Ещё один текст Берса, который можно "ассимилировать" с предыдущим ...

Этот системный анализ опирается на следующие методологические принципы:

• рассматриваются ограниченные целостные системы и/или их части;
• Онтологией каждой конкретной деятельности является единичное исполнение некоторого программного фрагмента подходящим исполнителем в соответствующей замкнутой операционной обстановке (см. ниже).
• рассмотрение должно быть конструктивным, т.е. отвечать на один из вопросов: "как этим пользоваться?" или "как это устроено?". Ответ на первый вопрос даёт нам внешнюю спецификацию, объясняя, что это и/или зачем это, а на второй — (проектное) описание, которое объясняет, почему это работает именно так.

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

годы ведущая парадигма и основные понятия

50-е Составление программ для ЭВМ (адресность, управление, подпрограммы, микропрограммирование);

60-е Выражение задачи "наЯВУ"* (языки, их основные структуры, описания и типы данных, блочность и модульность, трансляторы и интерпретаторы);

70-е Обеспечение эффективного использования ЭВМ (операционные системы, базы данных, прерывания, страничная и сегментная организация, кэширование, параллельность);

80-е Объектная ориентированность (объекты, сообщения, управление потоком данных и по событиям);

90-е Сеть, системы "клиент-сервер" (активные компоненты, асинхронные взаимо­действия, распределенная обработка).

*на языке высокого уровня (формулировка А. П. Ершова)

При этом на втором и третьем этапах с очевидностью возрастает отстранение человека от хода работы процессора и непосредственного исполнения запрограммированных действий. Растет и удельный объём системных программных и аппаратных компонентов компьютера. Возникает деление на системных программистов и пользователей, которые в принципе относятся к компьютеру по-разному.

Я начну с анализа исполнения отдельной конкретной деятельности. Либо о том, как она происходит ничего не известно и в этом случае это элементарная деятельность, либо её можно задать в виде некоторой структуры предписаний — программного фрагмента (ПФ). Однако и для элементарной деятельности мы должны уметь дать предписание, её вызывающее. Предписание — это обозначение, с которым связаны следующие атрибуты: исполняемая деятельность, — смысл предписания, его эффект (т.е. произошедшие от исполнения предписания изменения в окружающем мире), возможные значения-аргументы и значение-результат, а также оценка, позволяющая узнать, как завершилось исполнение предписания.

Для программного фрагмента можно определить единичное исполнение соответствующим исполнителем в замкнутой операционной обстановке. Оказывается воз­­можным отнести каждое из предписаний ПФ к одному из четырех родов: 1) структурное, явно задающее преемника (ов); 2) команду исполнителя; 3) обращение к объекту; 4) вызов протокола взаимодействия. В соответствии с этим определяется шесть составляющих операционной обстановки: а) программный фрагмент, б) исполнитель, в) перечень доступных объектов, г) перечень доступных протоколов, д) рабочая область для исполнителя, е) сигналы, связывающие исполнителя с внешним миром.

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

Исполнитель вызванной обстановки не обязан быть таким же как и у вызывающей. Программный фрагмент может быть структурирован как под поток управления, так и под поток данных. Операционная обстановка и единичное исполнение в ней информационно замкнуты, что обеспечивается ограничением доступа только к указанным в перечнях объектам и протоколам, замкнутостью ПФ по переходам. Кроме того предписания ПФ могут брать аргументы и возвращать результат только в рабочей области, недоступной извне. Отметим, что общее понятие программа "распределилось" между программными фрагментами, в которых сконцентрировались все исполняемые действия, объектами и операционными обстановками, заготавливаемыми на основе описательных компонентов программы.

Внутри обстановки исполнение каждого предписания ПФ является элементарной деятельностью и продвигает внутреннее время исполнения на один t-акт. Кроме полной формы обстановки, далее называемой Е-ка (читается "ешка" — от Environment и в честь А. П. Ершова), полезно рассматривать усеченные формы, такие как: L-ка (не нуждающихся в объектах и протоколах), С-ка (без внешних протоколов) и т.п.

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

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

Найти картинки к тексту!

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

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

Самыми простыми объектами являются, как известно, элементы памяти, например, регистры или ячейки, тип которых включает два метода запись и чтение. Предписание для записи может иметь вид ass(x, a), и приводит состояние ячейки х в соответствие со значением аргумента а. Обратное действие может быть задано предписанием взять (читать) значение valT(x), соответствующее состоянию, где Т — тип читаемого значения. Существенно, что одному и тому же состоянию объекта могут соответствовать прочитанные значения разных типов. В общем виде это можно выразить, если в цепочке имя - тип - объект согласиться относить тип к обозначению имя, а не к обозначению объект. Тогда возможны синонимические имена, например, номер - цел - регистр1 и назв - строк - регистр1, для одного и того же объекта, различающие его разное использование.

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

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

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

Заметим, что при обсуждении семантики программ почти всегда упускают из виду, что все программные конструкции суть системы знаков, и находятся в особенном знаковом мире. Однако еще в 1960 г. в работах Московского методологического кружка было показано [см. 3, 156-196], что свойства и связи вещей (т.е. отдельных целостностей реального мира) не только не совпадают со свойствами и связями их образов в знаковом мире — объектов, но и не являются их параллельным (изоморфным) отображением. Кроме того правила работы со знаками позволяют получать новые знаки, обозначающие знаковые формы, и для которых уже нет вещного соответствия в реальном мире. Важным примером такого знака может служить указатель — объект, обеспечивающий косвенную адресацию.

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

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

    I.     Всякое единичное исполнение должно завершаться;

    II.     Целостность и корректность доступов должны обеспечиваться;

  III.     При обращении к объекту для записи всякий другой доступ должен быть запрещен.

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

Известно сколько неприятностей причиняет так называемый "побочный эффект", имен­но поэтому при определении операционных обстановок столько внимания было уделено различным аспектам их замкнутости. Для объекта в отсутствие обращений его состояние не изменяется, однако при обращении всегда возможно изменение его состояния, что и отмечалось ранее как эффект соответствующего рода предписаний. Скажем, что объект информационно замкнут, если при обращениях к нему не могут измениться состояния ни в каких других объектах. Рассмотрим следствия замкнутости объектов. Во-первых, никакие объекты не могут иметь общие подобъекты, во-вторых, подобъект не может быть объектом, а в-третьих, ни один из методов объекта не может обращаться к какому-либо другому объекту. Такой перечень ограничений выглядит страшновато — список не объект, строка матрицы не объект, и экземпляр класса C++, со статическими объявлениями — тоже не объект. Однако если разобраться то окажется, что всё так и должно быть. Состояния подобъектов объекта суть части его состояния и отражены в его домене, а потому подобъекты несамостоятельны, и понятие замкнутости для них вводить не нужно. Все сразу станет ясным, если признать, что объектность — это статус, и что объект — понятие относительное, что он существует не вообще, а как объект в некотором подпространстве. Я считаю, что объекты должны быть замкнутыми, а средства объектно-ориентированных систем — подправлены.

Некоторые подобъекты могут рассматриваться как объекты в подпространстве домена объекта-хозяина, хотя некоторые — все равно нет, например, строки и столбцы в матрице. Однако любой подобъект можно представить как конфигурацию объектов в подпространстве объекта-хозяина. Например, работа автомобильного двигателя состоит из чередования тактов в его цилиндровых группах, но, разобрав двигатель на детали, мы не сможем положить на полку никакого объекта типа цилиндровая группа, однако можем указать конфигурацию деталей, являющуюся таковой. С другой стороны каждый составной объект можно рассматривать как конфигурацию его подобъектов, с совпадающим типом навигации. Доступ ко всем составляющим объектам этой конфигурации будет только через её начало. Однако в отличие от составных объектов конфигурации могут иметь общие объекты, доступные через начало как одной, так и другой, например, так может происходить при работе со списками.

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

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

Если поставить себя на место исполнителя операционной обстановки, то объектную парадигму можно характеризовать одной фразой: "Чтобы поручить эту деятельность кому-нибудь, нужно так задать обработку этих данных, что она будет осуществляться исключительно только указанными способами, хотя если никого не найдется, то я и сам с этим справлюсь", — именно это и заложено в инкапсуляцию. Иначе можно сказать, что проблема объективизации состоит в создании такой знаковой формы, чтобы можно было передать работу другому, может быть большему специалисту в какой-то конкретной деятельности.

Итак все предыдущее предполагало, что для выполнения некоторой конкретной деятельности берется реализующий её программный фрагмент, операционная обстановка для него и происходит требуемое единичное исполнение, осуществляемое активным исполнителем. Понятно, что содержание обстановки должно быть согласовано с содержанием программного фрагмента, а последний с возможностями исполнителя. Чтобы отчетливее представить, что за что отвечает, рассмотрим еще две усеченные формы операционной обстановки: X-ку — без исполнителя и F-ку — без программного фрагмента. X-ка, которая может также быть названа оболочкой операционной обстановки — это её статическая часть, которая может быть заранее построена (в той или иной степени готовности) системой программирования (с учетом её запасов готовых решений) по исходному тексту ПФ и спецификациям деятельности. При этом формируются перечни требуемых объектов и протоколов, определяется объем рабочей области с учетом типа необходимого исполнителя. Чтобы оценить роль F-ки зададимся на первый взгляд странным вопросом: "Что делает в операционной обстановке, сформированной для обеспечения единичного исполнения данного программного фрагмента, этот самый ПФ?". Хорошо подумав, найдем не менее парадоксальный ответ: "Мешает работать исполнителю!". Действительно, вполне возможно, что в обстановке запасены возможности работать с множеством объектов и протоколов, исполнитель снабжен богатым репертуаром команд, и из всего этого спектра ПФ вырезает тонкую единственную тропу, потому что в нем больше ничего не предусмотрено. Другими словами, сама F-ка представляет собой исполнитель с большими возможностями, чем исполнитель, входящий в неё в качестве активного элемента.

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

В свете сказанного выше рассмотрим диаграмму с двумя вершинами и связывающими их ребрами, на которых нет пометок. Будем считать, что эта диаграмма представляет систему с двумя состояниями, самостоятельно сменяющими друг друга, и назовем её "Тик-так" или активатор-1. Реальную вещь с такими свойствами легко построить из двух транзисторов и малого числа пассивных  элементов, — конденсаторов и сопротивлений, и называется она — мультивибратор. Со знаковым миром её онтологический образ, который я буду называть субъект, придется связать как новую независимую элементарную сущность. Далее, имея Тик-так, можно построить активатор-2, у которого тоже будет два состояния: первое "взять предписание из ПФ", а второе "исполнить предписание". Его детальное проектирование и постройку можно поручить фирме Intel, которая легко с этим справится.

Активатор-2 избавит нас от необходимости рисовать диаграммы состояний для сложных систем, так как известно, что любую из них можно заменить его продвижением по некоторому программному фрагменту. Более того, у нас уже почти есть исполнитель для операционных обстановок. Посмотрим еще раз на диаграмму активатора-2, но сосредоточимся на сей раз на интерпретации её стрелок, с помощью которых представляются переходы между состояниями. Назовем стрелку, выходящую из состояния S0, стрелкой "выполнить", а стрелку, выходящую из состояния S1, стрелкой "взять". Будем рассматривать каждую из них как предписание осуществить указанную конкретную деятельность. Представляемый таким образом субъект назовем активатор-3. Чтобы не путать новую интерпретацию со старой будем изображать стрелки этого субъекта с внутренними (активизирующими) предписаниями светлыми. Но если светлая стрелка есть предписание "выполнить", то можно заготовить некоторый ПФ для активатора-2 и запустить для его единичного исполнения (в качестве реализации этого предписания) соответствующую L-ку. Таким образом, исполнение команды уже можно представлять, состоящим из нескольких шагов, например, проверить, нет ли внешнего сигнала и, если есть, то исполнить предписание по реакции на него, а иначе обрабатывать выбранную команду и т.п. Логика дальнейшего расширения репертуара возможностей исполнителей более или менее очевидна.

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

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

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

Найти презентацию (14 картинок!)

https://telegra.ph/PEGAS-10-28