Семантическое будущее вычислительных технологий

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

Следуя подобным «общим» соображениям мы и позволим себе определение в качестве основной подлежащей решению задачи собственно задачу выведения из употребления характерного реальному программированию литературно «неудобоваримого» стиля привычных для математической лексики или стиля мышления союзов и предлогов. Кстати, в смысле собственно принятых в наше время представлений программирования приближение к подобной структуре и позволяет отождествление именем «функционального» стиля программирования. В нашем же случае «подлежащим замене» функционалом тогда и следует признать привычный для практики программирования стиль представления данных в виде всякого рода «конъюнктивов» теперь уже на характерные для естественной семантики высказывания о действиях отслеживания, замены, составления и, возможно, каких-либо иных форм именования, обозначающих собой некие операции обработки данных. Также в значении некоего общего принципа мы и позволим себе задание условия и полного отказа от использования скобок или выражений подобных «begin» и «end». В таком предлагаемом нами условном «решении» мы и позволим себе предполагать возможность реализации принципа использования «зарезервированных слов» и завершения любого предыдущего выражения в момент добавления в последовательность «изложения» очередного зарезервированного слова. Хотя практическая реализация подобного проекта вряд ли позволит признание избегающей неизбежной сложности, но, как нам представляется, такой проект не будет предполагать понимание и в качестве же «безнадежно далекого» от практической реализации.

В таком случае, какие именно принципы и следует использовать для построения комплекса понятий и отношений воображаемого «повествовательного» языка программирования? Прежде всего, реализацию подобного алгоритмического языка и следует начать построением структурной модели, само основание которой и следует составить структурной «модели конструкции» из практики инженерной деятельности. Любопытно, что в технической практике практически каждая конструкция позволяет изложение ее принципов построения посредством того же технического описания, и подобную доступность для понимания теперь уже и следует воспроизвести для структуры программы.

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

Напротив имени агрегата также возможно и указание его состояния на момент запуска программы:

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

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

Далее необходимо удаление всех, какие только возможно понятий математической логики, например, оператора «if» (если). Превосходным именем обработчика, способным заменить оператор «если» и следует понимать употребление слова «сторож». И, одновременно, для «сторожа» не помешает введение и альтернативного понятия, исполняющего некую противоположную функцию, здесь вполне допустимым и следует понимать использование слова «турникет». В таком случае на «сторожа» и возможно возложение функции остановки по условию равенства значения, когда функцию «турникета» и составит операция запуска следующих «узла» или «обработчика» по условию фиксации некоего оговоренного значения. В таком случае «сторожу» и следует давать «задания» или «поручения» в виде условий останова:

и перехода

или в сборе

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

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

Для объявления «рам», «агрегатов» и «индексов» тогда и следует допустить использование зарезервированного слова «учредить» -

Считывание также не помешает обозначить словом «получение», а выдачу - словом «раскрытие» -

Для получения значения нелокальной переменной из другого агрегата или узла также следует предусмотреть зарезервированное слово, например, «забрать» -

Вспомогательные библиотечные формы наподобие библиотек *.dll тогда и позволят отождествление посредством зарезервированного имени «обеспечение», в отношении которого также возможно использование зарезервированного имени функции, скажем «обращения« за обеспечением. Специфические формы обеспечения наподобие записываемых в регистры и файлы конфигурации данных также следует определять под зарезервированным именем «атрибуты».

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

Кроме уже рассмотренных основных принципов здесь равно же следует ожидать и определения характерного порядка, устанавливающего особый способ воспроизведения связей, что в существующих ныне алгоритмических языках и понимаются в значении методов «объектно-ориентированного» программирования. Здесь не следует вносить изменений в непосредственно подобные методы, но непременно и следует озаботиться изменением описывающих их понятий. В естественной для семантического представления терминологии явно не следует использовать понятие «объект», заменив его обозначающими связи либо отношения понятиями, скорее всего, «макета» (матрицы) и «оттиска». В таком случае здесь и следует предполагать возможность следующего порядка описания:

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