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

Состав работы:


Идея работы


 

Онтология «условий ассоциации»


 

Единый модуль интерфейса и результатов работы алгоритма


 

Общая типология совершаемых алгоритмами действий


 

Семантические форматы


 

Типы алгоритмических инструментов


 

Концепт элементарного оператора - процедура «запись»


 

Применение средств обработки данных


 

«Алгоритмически чуждые» структуры агрегирования данных


 

Алгоритм с точки зрения «узкой» и «широкой» интерпретации


 

Реальный алгоритм - единая схема иерархии и вложенности


 

Гипотетическая «семантически строгая» запись


 

Фиксированные алгоритмические комплексы – «устройства»


 

Унификация системы операций


 

От «записей» к хранилищам записей


 

«Состояния настройки» или ситуативные атрибуты модулей


 

Библиотечная организация коллекции процедур


 

Условная лексическая среда «повести о вызове и реакции»


 

Два вероятных примера «программного нарратива»


 

Возможная рационализация «программного нарратива»


 

«Альтернативная философия» алгоритма


 

Даруемая алгоритмической системой «свобода творчества»


 

Два вида алгоритмической семантики - системная и внешняя


 

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

§17. Условная лексическая среда «повести о вызове и реакции»

Шухов А.

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

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

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

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

рама 'название'
агрегат 'название'
....
агрегат 'название'

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

рама 'название'
агрегат 'название' активизация
....
агрегат 'название'

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

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

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

сторож - 2< индекс <5

и перехода

сторож
удержал 3 - агрегат 'название' активизация
удержал 4 - агрегат 'название' активизация

или в сборе

сторож - 2< индекс 'название' <5
удержал 3 - агрегат 'название' активизация
удержал 4 - агрегат 'название' активизация

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

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

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

учредить
индекс 'название' нелокальный
сведения 'название'

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

получить сведения 'название'
раскрыть сведения 'название'

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

индекс 'название' забрать индекс 'название' узел 'название'

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

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

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

макет 'название' воспроизвести в оттиске 'название'

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

 

Следующий параграф: Два вероятных примера «программного нарратива»

 

«18+» © 2001-2025 «Философия концептуального плюрализма». Все права защищены.
Администрация не ответственна за оценки и мнения сторонних авторов.

eXTReMe Tracker