Комплекс возможностей, рисовавшийся в нашем воображении как «повествовательный» язык программирования, как и всякое повествование, должен соответствовать и некоторой «лексической норме». Тогда строго следуя подобному принципу, мы откажемся от метода использования логических конструкций, на чем в наше время построен любой современный язык программирования. В нашем случае такое же в точности содержание, что подлежит фиксации посредством конструкций, применяемых в реальных языках программирования, найдет выражение посредством понятий и оборотов естественного языка, в основном представленных в виде таких «атомарных» понятий, как понятия «отслеживание», «контроль» или «несение караула». По сути, нашу концепцию мы построим на основании оценки, что конструкции современных языков программирования выстроены посредством форм и структур, каким-то образом тождественным этой группе понятий. Тогда в следующей части нашей работы мы и обратимся к попытке представления примеров передачи содержания, характерного для модулей реальных программ посредством такого рода обиходных понятий, а сейчас ограничимся изложением лишь общих соображений.
В том числе, один из элементов этих «общих соображений» - определение в качестве основной подлежащей решению задачи равно и задачи выведения из употребления присущего реальному программированию литературно «неудобоваримого» стиля союзов и предлогов, привычных для математической лексики или стиля мышления. В этом случае нам и подобает озаботиться заменой привычного в практике программирования стиля представления данных, определяющего порядок задания различного рода «конъюнктивов» теперь и присущими естественной семантике высказываниями о действиях отслеживания, замены, составления и, возможно, иных форм образования ассоциации, обозначающих собой операции обработки данных. Также нашу концепцию языка программирования мы построим в стилистике, не предполагающей выделения знаков начала или конца операции - скобок или выражений «begin» и «end». Мы будем исходить из принципа, что повествовательному языку программирования дано употреблять лишь «зарезервированные слова» и любое предыдущее выражение завершается в момент употребления следующего зарезервированного слова. Хотя практическая реализация подобного проекта вряд ли позволит признание избегающей неизбежной сложности, но, как нам представляется, такой проект не будет предполагать понимание и в качестве «безнадежно далекого» от практической реализации.
После прояснения некоторых начальных контуров нашего плана теперь нам следует определиться и в части порядка построения комплекса понятий и отношений воображаемого «повествовательного» языка программирования. Прежде всего, реализацию подобного алгоритмического языка следует начать построением структурной модели, само основание которой и надлежит составить структурной «модели конструкции», заимствованной из практики инженерной деятельности. Любопытно, что в технической практике практически каждая конструкция позволяет изложение принципов ее построения посредством технического описания, и подобную доступность для понимания также следует воспроизвести и для структуры программы.
Следом тогда надлежит определиться и с предметом «основных комплексов» мыслимого нами литературно «выразительного» языка программирования. То, что в стандартных языках программирования носит имя «программы», здесь будет предполагать отождествление под именем «рама», на что будет предполагаться «навеска» того нечто, что можно расценивать теперь уже в значении «агрегата» (в обычном программировании - процедур и функций). То есть модуль программы приобретет тогда и следующий вид:
рама 'название'
агрегат 'название'
....
агрегат 'название'
Напротив имени агрегата также возможно указание и его состояния на момент запуска программы:
рама 'название'
агрегат 'название' активизация
....
агрегат 'название'
Далее, если следовать вниз по структуре, то агрегатам следует содержать «узлы» и низший уровень иерархии - «обработчики». В таком случае «обработчики» будут предполагать обобщение и в нечто стандартную библиотеку обработчиков, где будут представлены посредством нарратива, в порядковой форме перечисляющего исполняемые ими операции.
За типами переменных, скорее всего, следует сохранить тот же вид, что отличает их и на сегодняшний день, за исключением отдельных изменений. Первое, переменным сразу следует определять вероятное назначение - либо это переменные для хранения служебной информации непосредственно программы, либо это переменные (здесь сразу следует понимать - это еще и массивы переменных), предназначенные для хранения информации, внешней для программы. Переменные, хранящие служебную информацию, тогда надлежит определить под именем «индексы», а переменные, хранящие внешнюю информацию - под именем «сведения». Также следует переименовать и непонятные логике повседневной речи «массивы», заменив их двумя специальными именами - «кляссер» для пустого массива, и «коллекция» для помещаемого в массив наполнения. Такая модификация и позволит определение программного события выделения «кляссера» и помещения в «кляссер» равно и нечто «коллекции», что и обретет осмысленные формы тогда и на взгляд не математически ориентированного понимания. Далее, индексы, сведения и коллекции, как и это и принято в современном программировании, следует определять в качестве локальных и нелокальных; по умолчанию тогда они будут предполагать задание в качестве локальных, ограниченных конкретным «агрегатом» или «узлом», когда лишь особым образом будут подлежать отождествлению в качестве нелокальных (см. ниже). Помимо того, вместо «константы» может потребоваться использование и зарезервированного слова «заданное значение».
Далее необходимо удаление всех, какие только возможно понятий математической логики, например, оператора «if» (если). Превосходным именем обработчика, способным заменить оператор «если» и правомерно признание употребления слова «сторож». И, одновременно, для «сторожа» не помешает введение и альтернативного понятия, исполняющего некую противоположную функцию, тогда здесь можно воспользоваться словом «турникет». В таком случае на «сторожа» и возможно возложение функции остановки по условию равенства значения, когда функцию «турникета» и составит операция запуска «открытого шлюза» по условию фиксации некоторого оговоренного значения. В таком случае «сторож» будет исполнять «задания» или «поручения» в виде условий останова:
сторож - 2< индекс <5
и перехода
сторож
удержал 3 - агрегат 'название' активизация
удержал 4 - агрегат 'название' активизация
или в сборе
сторож - 2< индекс 'название' <5
удержал 3 - агрегат 'название' активизация
удержал 4 - агрегат 'название' активизация
Возможно, что практическая реализация подобных модулей потребует использования не только понятия «активизация», но и понятия «выполнение», необходимость в котором будет подлежать определению на практике.
Далее, развитие «повествовательного языка» программирования также невозможно и вне определения полного комплекса типовых обработчиков, сколько бы не насчитывалось их вероятных разновидностей, и, соответственно комплектования библиотеки типовых обработчиков. В частности, здесь вполне возможно использование зарезервированных имен наподобие «добавления» или «уменьшения» индекса и т.п.
Для объявления «рам», «агрегатов» и «индексов» тогда возможно задание зарезервированного слова «учредить» -
учредить
индекс 'название' нелокальный
сведения 'название'
Считывание если мыслить его в логике естественного языка, лучше обозначить словом «получение», выдачу - словом «раскрытие» -
получить сведения 'название'
раскрыть сведения 'название'
Для получения значения нелокальной переменной из другого агрегата или узла также следует предусмотреть особое зарезервированное слово, например, «забрать» -
индекс 'название' забрать индекс 'название' узел 'название'
Вспомогательные библиотечные формы наподобие библиотек *.dll в этом случае лучше обозначить при помощи зарезервированного слова «обеспечение», которое также полезно дополнить и зарезервированным именем функции, скажем «обращения« за обеспечением. Специфические формы обеспечения наподобие записываемых в регистры и файлы конфигурации данных следует определять под зарезервированным именем «атрибуты».
В отношении предмета общей структуры программы следует принять, что «раме» надлежит включаться в себя то непременно «агрегаты» или «узлы». Но при этом агрегаты и узлы следует вознаградить и возможностью обмена содержанием - то есть обмена индексами, сведениями или коллекциями. Следует также придерживаться указанного выше общего принципа, что разделители модулей программы то непременно же зарезервированные слова, и в этом отношении, возможно, следует лишь озаботиться заданием признака завершения «рамы», скажем, тогда и понятия «завершение».
Кроме уже рассмотренных основных принципов здесь равно следует ожидать и определения характерного порядка, устанавливающего особый способ воспроизведения связей, что в существующих ныне алгоритмических языках и понимаются в значении методов «объектно-ориентированного» программирования. Здесь не следует вносить изменений в как таковые подобные методы, но надлежит заменить описывающие их понятия. В естественной для семантического представления терминологии явно не следует использовать понятие «объект», заменив его обозначающими связи либо отношения понятиями, скорее всего, «макет» (матрица) и «оттиск». В таком случае здесь будет иметь место тогда и такой порядок описания:
макет 'название' воспроизвести в оттиске 'название'
На наш взгляд, ряд высказанных здесь идей все же надлежит расценивать как констатацию лишь наиболее существенных принципов условной «лексической среды» повествовательного языка программирования, откуда также необходимо рассмотрение равно и возможных вариантов текста программы, написанного с использованием такого рода конструкций. Подобные примеры будут представлены в следующей части настоящего анализа.