иерархическая система функционального программирования

• profydemocracy

  Posts 1

  Joined: Wed Feb 04, 2009 1:26 pm

  Wed Feb 04, 2009 1:48 pm

  viewtopic.php?f=4&t=1210
  Иерархическая система функционального программирования (возможно - с индексным доступом и описанием объектов через массивы).
  
  Здравствуйте, я давно уже бросил программирование в пользу гуманитарной области, однако, у меня была "голубая мечта", сделать (в идеале) на основе ассемблера язык программирования, (в идеале, включая и несколько новую технику вызова BIOS). Насколько могу вспомнить, идея на основе двух-трёх техник: 1. а) запись программы в функциональном стиле (то есть аргументы естественно готовы к асинхронному одновременному вычислению, хотя это и не обязательно, однако, вполне можно сразу зарезервировать соответствующие данные); при этом б) каждая функция состоит из списка последовательно исполняемых слов, без ветвлений, что потенциально позволяет несколько ускорить вызов слов списка в) ветвления осуществляются через вызов функций 2. Строго иерархическое деление словарей языка (по мотивам Форта, где каждый программист - системный или прикладной - работает строго с понятийным словарём своего уровня). Что потенциально позволяет строить высокоинтеллектуальные системы. 3. Если традиционно мы строим модели мира из данных в структурах и библиотек функций (объекты и действия) или из данных в структурах и соответствующих им функциях (объекты и действия для них), то здесь мы строим модель мира из функций со структурированными аргументами (моделями объектов из реальности) и с выходом в аргументы других функций (действия и структура объектов для них, но уже для следующего понятийного уровня и, соответствующего словаря функций). и 4. (Это скорее из области технических приёмов, для реализации прямых связей) - доступ к объекту через его условный номер в различных массивах.
  
  Дальше скопирую свою старую "рекламу" (извиняюсь, если что не так излагаю): http://igor-mikhaylin.livejournal.com/3487.html
  хотя я уже давно бросил программирование, но всё же мне хотелось бы иметь что-то в таком роде:
  Экран:
  1. что вижу, значение того могу установить непосредственно, кликнув мышкой (например, номер страницы в окне текстового редактора, букву в тексте, параметр команды в строке команд, имя файла в строке инфы о текущем, просматриваемом файле и т.д. и т.п.), хорошо использовать выпадающие менюшки, при возможности.
  2. что вижу, с тем могу что-то сделать, кликнув другой кнопкой мышки и выбирая нужное действие из появившегося меню.
  3. и, конечно, получить полное описание этого объекта, как-нибудь кликнув по нему.
  
  Иерархия Функциональных Индексов:
  1. любой объект реального или условного мира представляется некоторым индексом (номером), а какие-то его описания представляются в соответствующих массивах описаний, доступ к которым осуществляется по индексу, если какой-то объект не имеет описания, то соответствующий элемент в массиве остаётся пустым. (Например, слово "стол" - это текстовая строка из словаря русского языка, "a table" - соответственно английского, а индекс соответсвующий понятию "стол" - может быть, например, - 1000000...0000000; также может быть массив звука, или обобщённого изображения, описания использования, технологии производства, и т.д. - до бесконечности. И если на нижнем уровне некоторый текст имел традиционный вид буквенной кодировки, то на следующем уровне он уже имеет воспринятый/интерпритированный вид индексов, соответствующих некоторым понятиям - словам в словаре уровня.)
  2. если эти индексы стандартизированы для компьютеров некоторой сети (например, как IP номера internet), то они могли бы использовать информацию и программы на всех машинах сети, обмениваясь запросами в терминах стандартных индексов.
  3. - индексы группируются в словари внутри некоторого уровня
  - и в целом разделяются по уровням,
  - причем интерпритирующие или управляющие функции, в качестве параметров не могут использовать индексы любого из уровней в беспорядке, но только строго определённого уровня - предыдущего нижнего для интерпритации или следующего, вышестоящего для управления. (это подобно уровням организации операционных систем: уровень аппаратных прерываний BIOS, уровень супервизора ОС, уровень пользовательской ОС, уровень пользователя, уровень программ пользователя; и каким-то программам в этих уровнях, но любая программа-функция некоторого уровня может использовать только набор параметров с соседнего нижнего уровня для интепритации или с верхнего - для управления.),
  - а сама управляющая программа выглядит как последовательный список слов-функций некоторого определённого уровня (и никакого другого),
  - причём, параметры функции могут вычисляться асинхронно/параллельно, для этого среди параметров имеются два стандартных: число параметров функции (это соответствует уровню порога нейрона) и число невычисленных параметров (это соответствует уровню возбуждения нейрона), когда число невычисленных параметров равно 0, функция срабатывает, блокирует вычисление параметров (0-счётчика) и выполняет какие-то программные действия, интерпритирующие или управляющие, после чего число невычисленных параметров восстанавливается и функция готова принимать новые значения параметров. - это как бы программистская модель ПОРОГОВОЙ ЛОГИКИ нейронов. (Интерпритирующая функция может вычислять и передавать параметры для других функций, следующего уровня, и декрементировать их число невычисленных параметров. Управляющая функция может активизировать вычисление последовательности её списка управляющих слов словаря, соответствующего ей уровня.)
  4. Предпочтительнее иметь и более реальные модели - знания, например, вместо функции опроса буфера клавиатуры, (или - вместе с ней) лучше иметь, доступную пользователю, точку вызова пользовательской подпрограммы-функции из стандартной программы-функции обработки прерывания клавиатуры в ОС или в BIOS.
  
  А вам как?
  
  несколько слов о реализации
  igor_mikhaylin
  2004-08-30 05:43 am UTC (ссылка)
  
  1. Многое зависит от подхода, от дисциплины. Хотя, предложение выглядит прежде всего, как вариант функционального программирования с введением структур значений для признаков объектов через массивы, но этот подход так же можно рассматривать, как программирование описанием данных. То есть с самого начала и до конца, мы имеем в распоряжении некоторую среду - описание ситуации и наборы программок, а также сами занимаемся описанием ситуации и готовим некоторые группы простых программок. Это можно рассматривать как сквозную базу данных и программ полностью описывающую компьютер, ОС, прикладную сферу и т.д. Именно это является конечной целью.
  Хотя, возможно что, для начала можно написать несколько переводчиков (не знаю как они реально устроены), здесь плюс будет такой, что если вы на Мадагаскаре например, напишете свой уникальный переводчик с мадагаскарского на чешский, то все пользователи сразу же смогут переводить тексты с любого из своих языков на мадагаскарский, а вы получите возможность переводить не только на чешский, но и на все остальные языки уже доступные в системе.
  1. Возможно, что иметь большие и сильно разреженные массивы данных (для индексов-понятий) не эффективно, но не обязательно и городить в этом случае сложный математически-программный огород с кешированием и т.д. (хотя, я помню, что аппаратура и ОС таким образом распределяют память, что мы и безусловно используем)...
  Здесь важную роль играет логическая организация массивов. Во-первых, индексы разделены на логические уровни (например, ассемблер, программа из ассемблерных подпрограмм, и т.д.), а во-вторых, на этих уровнях индексы (слова) объединены в логические группы (словари). И в результате мы можем иметь вместо глобальных массивов для всех индексов-слов в целом, организованные тематические массивы меньших размеров, которые могут уже быть более компактными и заполненными (эффективными) и приемлемыми для страничной Операционной Системы. Но, конечно, если мы имеем только один простой вариант массивов, это упрощает нам программирование и ускоряет доступ, а если мы всё же введём несколько вариантов организации массивов, нам понадобятся заголовки, доступ замедлится, хотя и станет универсальным.
  
  Вот, например, три возможных организации массивов:
  I)
  1) Для массива с очень разреженными данными, мало заполненный: "сжатый массив" - массив структур, где первый элемент является значением индекса в массиве, а второй - значением данных для этого индекса. (Последовательный просмотр индексов и выдача значения.)
  2) Для нормально заполненных массивов - "обычный массив значений", выборка по индексу.
  3) "Битовый массив" , в этом случае индекс является запросом на ответ Да/Нет (Есть/Нет), который мы и получаем проверяя, соответствующий индексу бит. (В этом случае мы имеем доступ отличающийся от нормального; а именно, если обычно мы запрашиваем, например, для индекса-"слон", из массива "цвет", значение, то получаем ответ - "серый"; а в битовом массиве мы делаем запрос по индексу-"слон", из массива "красный", и получаем ответ "нет" (бит 0). )
  Всё же скорее это подошло бы для флагов каких-то более важных и однозначных событий, признаков, состояний.
  ---
  II) массивы скорее всего - динамически наращиваемые, через списки блоков значений (как обычных, так и сжатых массивов) или просто списки каких-то элементов - функций/индексов/слов ...
  --------
  Здесь нам всё же понадобятся некоторые "Заголовки (теги) Данных", которые будут определять формат данных (и способ их обработки) - простой массив, сжатый, список массивов, битовый массив - и т.д. Хотя, мы можем просто передать управление Функции этого массива и параметр - некоторый индекс (возможно лучше - в глобальной переменной), а она вернёт нам значение для этого индекса! (и нет проблем, мы можем и не знать, как устроены её данные!)
  
  
  Из прошлого опыта, в своё время я имел ввиду, например:
  1. Функциональное программирование: Удобно писать программу с самого верха - с конечной функции, а затем уже писать функции вычисляющие её параметры.
  Но тут есть одно "но":
  а) Так как на самом деле традиционный компилятор, например, - "С", стандартно вызывает функцию/процедуру с уже вычисленными на стеке параметрами и с некоторыми глобальными переменными. Это значит, что компилятор просматривает исходный текст функциональной программы и строит вызовы, начиная снизу и постепенно добираясь до вызова на выполнение итоговой функции. Для пороговой логики этому процессу - "Снизу Вверх" - соответствует вызов на выполнение функции после завершения вычисления всех её параметров (причём, если порог равен числу параметров, то это будет "пороговое И", а если порог равен 1, то запуск произойдёт при вычислении любого из параметров - это будет "пороговое ИЛИ", в принципе можно ввести и флаг блокировки/приостановки запуска, когда после снятия блокировки проверится текущий порог).
  Это - снизу вверх -, вероятно, будет полезно для опознания и реакции на какие-то произвольные "нижние" события, например прерывания.
  б) но с другой стороны интерпретатор будет выполнять функцию/процедуру сразу. В нашем (функциональном и пороговом) случае это значит, что наша функциональная программа на самом деле выполняется "Сверху Вниз", как она и была написана, и итоговая функция инициирует запуск функций, вычисляющих её параметры, (в случае параллельных вычислений, получая результаты с помощью пороговой логики "И"/"ИЛИ") и тут уже от неё самой зависит как ей удастся получить необходимые параметры. Это выполнение кажется громоздким, так как мы имеем одновременное выполнение целого дерева функций/процедур, но всё же техника идёт вперёд ... Здесь можно вспомнить и такой интерпретатор как ФОРТ (forth). Где мы имеем опыт организации слов в списки словарей (в том числе выражающийся в наличии режима построения-создания слова и режима выполнения слова, когда выполняются разные действия), и наглядное программирование в виде последовательности вызовов этих слов (хотя обратная запись для предварительного вычисления параметров на стеке, изрядно портит эту наглядность). То, что это именно интерпретатор, мы видим, что даже число 2, например, в качестве параметра, передаётся на стек особым словом/программой с именем "put2", например.
  Это - "сверху вниз", вероятно, хорошо подходит для инициативы сверху.
  в) Итак, в общем, для нашего случая, - некоторая верхняя функция выполняется и вызывает вычисление необходимых ей параметров инициируя нижние функции. Но это ещё не всё! После вычисления всех параметров Функция начинает собственно своё дело и в свою очередь вычисляет что-то и передаёт значение как параметр куда-то наверх, для чего она запускает в работу простую прямую (без ветвлений) последовательность вызовов функций её уровня с уже заданными, вычисленными значениями параметров.
  ( г) кстати, в функциональном программировании, для обработки стандартных списков для данных, есть идея рекурсии, когда ваша (ещё недописанная) функция (уже) - или вызывает саму себя, или выходит по обнаружению конца списка, - что выглядит красиво; и даже накладные расходы можно при желании уменьшить, если вместо серии "пустых" ret ret ... ret ret подсчитать число вызовов и сбросить со стека соответствующее число адресов возврата и выполнить один итоговый ret. Но мне всё же кажется проще организовать обычный цикл внутри функции для обработки списков.
  (Ответить) (Уровень выше)
  
  
  Значит получается, что наш "Вызов Функции" через Функциональный Индекс для массивов (- N) выглядит как-то так:
  
  ФИNу-управления для N (общее число параметров, порог - необходимое число параметров (это или 1, или общее число пар-ров), текущий порог-число вычисленных (или невыч-ых) параметров, ФИNд-действия N для запуска по переходу через порог (все параметры уже вычислены в этой строке вызова и передаются), ФИп1у-управления 1-го пар-ра, ФИп2у-управления 2-го пар-ра, ....)
  
  (кроме того может быть точка входа, для создания структуры этого индекса, в режиме создания-подготовки, как в Форте)
  
  Где так же важно, что действующая часть - это наглядная, простая (без ветвлений!) последовательность вызовов процедур, с уже вычисленными параметрами.
  
  Ну, а попытка запуска, индекса действия N, осуществляется каждый раз после вычисления и передачи очередного параметра для индекса управления N, если текущий порог = 0

  • Quote