Система типов для компонентного программирования. - Философия программирования

Очень вкратце(если не понятно я буду уточнять) о модели компонентного программирования:
Все сущности в программе делятся на две группы:

  1.Компоненты("жесткая" часть), по аналогии с компонентами электронных схем.
      Делятся на:
        1.Средства создания программ:
            1.Модули, состоят из контейнеров.
            2.Контейнеры(переменные) значений, для хранения значений.
        2.Вспомогательные средства:
            1.Типы значений.
  2.Значения("мягкая" часть), по аналогии с сигналами электронных схем.
      Делятся на:
        1.Приметивные:
            1.Значения-данные, содержат данные.
            2.Значения-код(лямбды), содержат код.  
        2.Структурные, состоят из примитивных.

Это можно представить так (зленные стрелки — путь прохождения значений):

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

   PIXIL DATA [3] 0      \\Значения типа "PIXIL" это значения-данные, имеют размер в 3 байта и значение по умолчанию для этих байт 0.

И тип "FOO":

   FOO CODE [PIXIL,BYTE][BO0L] (){}() \\Значения типа "FOO" это значения-коды, принимающие два аргумента типа "PIXIL" и "BYTE", и возвращающие одно значение типа "BO0L",
                                      \\значени по умолчанию для этого типа ничего не делает.

При помощи типа "FOO" можно например реализовать оператор сравнения типа "PIXIL" с типом "BYTE" ():

   == FOO (A,B){                      \\Это определение контейнера
               false => R
               IF (A)Byte[0] == B {
                 IF (A)Byte[1] == B {  
                   IF (A)Byte[2] == B {truth => R}}}  
               }(R)

Типы "BYTE", "BO0L" являются базовым потому для них есть реализация операторов "==","=>","IF",
возможность работать с значением на уровне байт "(\*Имя_контейнера*\)Byte[\*Номер_байта*\]", тагже базовая.
Другой пример:

  \\Определения.
    S PIXIL \\Опеределение контейнера для значений типа "PIXIL".
    G FOO   \\Для значений типа "FOO"
  \\Код
    (A,B){\*Чего-то делаем с "PIXIL" и "BYTE" и возвращаем "BO0L"*\}(R) FOO => G  \\Помещаем значение типа "FOO" в контейнер "G"(присваиваем переменной).
    G(S,1) => S \\Вызываем помещённое в "G" значение.

Как вы считаете:
1.Каковы недостатки, такой модели и системы типов?
2.Жизнеспособно ли это в принципе?
3.Не слишком ли это сложно?
4.Неявное приведение типов, насколько оно нужно?
Спасибо.

Здравствуйте, AlexCab, Вы писали:

AC> 1.Каковы недостатки, такой модели и системы типов?
1. Непонятно, какие проблемы решает такой подход. Точнее, чем он лучше тысячи и одного велосипеда?
2. Неочевиден смысл введения кучи сущностей. Чем контейнеры принципиально отличаются от глобальных переменных? Если это они и есть — зачем изобретать новые термины?
3. Насколько я понимаю, методов как таковых не существует, всё — на каллбаках. Круто, но, опять-таки — зачем?
4. Неплохо бы увидеть описание структурных типов. Для начала — как будет выглядеть тип Screen, имеющий произвольное разрешение в пикселях (Pixel)?

AC> 2.Жизнеспособно ли это в принципе?
Без вводной части и обоснования всех введённых концепций/терминов — нет.
AC> 3.Не слишком ли это сложно?
Если постараться заменить свои термины общепринятыми — тоже нет.

AC> 4.Неявное приведение типов, насколько оно нужно?
It depends. Если под ним понимается возможность неявного приведения без потерь — из byte в int или из Time к DateTime (при условии явного объявления implicit cast operator) — пойдёт. Если имеется в виду, что корректность любого присваивания будет проверяться динамически, в рантайме — велкам к скриптовым языкам и прочей мелочи.

Здравствуйте, AlexCab, Вы писали:

AC>Как вы считаете:
AC> 1.Каковы недостатки, такой модели и системы типов?
AC> 2.Жизнеспособно ли это в принципе?
AC> 3.Не слишком ли это сложно?
AC> 4.Неявное приведение типов, насколько оно нужно?
AC>Спасибо.

Вообще программирование "как создание электронных схем" — интересная тема. Все вроде бы не против, идея давно известна, но никто толком ничего в этой области не делает. Наверное, идея слишком далека от архитектуры современных компьютеров и операционных систем.
1. Электронная схема работает вся сразу и одновременно. Каждый компонент — параллельный поток. Каждая часть компонента — параллельный поток. Каждый транзистор — тоже фактически параллельный поток, пусть и примитивный.
В программах как правило один поток, ну два-три. Если это сервер, то потоков — по числу клиентов. Создание потоков — достаточно дорогая операция, и переключение между ними — тоже. А "электронно-компонентная" парадигма в идеале требует, чтобы каждая операция, каждый if и else был отдельным потоком.
2. Электронная схема создается раз и навсегда. Она действительно "жесткая". В программе сущности появляются и исчезают динамически. К примеру, если в схеме есть, к примеру, 4 дешифратора, то их ровно 4 и не больше не меньше. Схема не может сама динамически подпаять себе еще парочку дешифраторов во время работы

В программе потоков с аналогичной функцией может быть сколько угодно — достаточно просто вызвать функцию создания потока.

Но тем ни менее парадигма имеет право на жизнь — при работе с крупными программными модулями. К примеру, межпроцессное взаимодействие. Всякие COM-объекты построены в какой-то степени на этой парадигме... Графы DirectShow например вообще очень похожи на электронные схемы.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, x-code, Вы писали:

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

G>А причем тут архитектура? Вообще говоря электронные схемы представляют из себя программы на ФЯ. Отдельные компоненты — функции, дорожки соединяют входы и выходы функций.
электронные схемы — это скорее http://en.wikipedia.org/wiki/Flow-based_programming. Что именно у ТС — я не понял.
G>Правда в этих системах не всегда есть "чистота", скорее конструкция похожа на монаду State и еще некоторые "функции" недетерминированы (но почти все свободны от сайд-эффектов).
А что за нечистота в монаде State?

Здравствуйте, Sinix, Вы писали:
AC>> 1.Каковы недостатки, такой модели и системы типов?
S>1. Непонятно, какие проблемы решает такой подход. Точнее, чем он лучше тысячи и одного велосипеда?
По видимому не чем, но мне интересна эта тема.
S>2. Неочевиден смысл введения кучи сущностей.
Что вы имеете ввиду? Я наоборот стараюсь свести их число к минимуму, но без потери возможностей.
S>2.Чем контейнеры принципиально отличаются от глобальных переменных?
Они ближе к контейнерам из STL нежели на классические переменные, к тому же будут в основном локальными.
S>2.Если это они и есть — зачем изобретать новые термины?
Новые термины нужны чтоб избежать путаницы. Читатель встречая в тексте новый термин или использование не совпадающее с ранее известным значением,
думает "WTF?" и лезет в документацию смотреть, ну или закрывает вкладку браузера

Но оба эти варианта лучше чем, по ходу чтения, каждый раз он будет думать "Это ведь переменная, какова с ней происходит?".
S>3. Насколько я понимаю, методов как таковых не существует, всё — на каллбаках. Круто, но, опять-таки — зачем?
Методы есть но более высоком уровне(уровне модулей), потому использоваться они будут гораздо реже чем в ООП например. Методы это также контейнеры.
S>4. Неплохо бы увидеть описание структурных типов. Для начала — как будет выглядеть тип Screen, имеющий произвольное разрешение в пикселях (Pixel)?
Ох, это обширная тема

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

Пакет может содержать неизвестное, на момент компиляции, число элементов но эти элементы должны иметь одинаковы тип.
Далее, контейнеры длятся на:
1.Примитивные — могут хранить только одно значение.
2.Структурные — могут хранить много значений.
Всего три вида:
"ARRAY" — Могут быть многомерными, обращение только по номеру элемента.
"UNION" — Только одномерные, обращение по номеру и по имени элемента.
"HEAP" — Одномерные, обращение только по номеру элемента, произвольное число однотипных элементов.
Контейнер "статический" если не содержит и не является "HEAP", иначе "динамический".
Число элементов и выход указателей за границы проверяются динамически, типы значений статически.
Если пакет и контейнер имеют одинаковую структур(число, тип, положение элементов), то пакет может быть помещён в контейнер(структурная типизация).
Таким образом для работы с, например, битмапом произвольного размера необходим динамический контейнер который может быть определён так:

\\Опеределения
  Screen UNION[                  \\Структурный контейнер
              Height INT         \\Высота
              Width INT          \\Ширина 
              Bitmap HEAP PIXIL  \\Куча пикселей 
              ]
\\Код
  Resise(Screen,640,480) => Screen \\Подгонка размера изображения

Пример определения процедуры для работы с изображениями:

IMAGE PACKEG[INT, INT, HEAP PIXIL]   \\Чтобы каждый раз не описывать пакет определим для него тип, 
                                     \\можно использовать этот тип также для определения контейнера и писать просто: Screen IMAGE
PROCIMG CODE [IMAGE,INT,INT][IMAGE]  \\Тип для значения-код, тот тип можно использовать для любых процедур имеющих такие же аргументы и результат.
Resise PROCIMG (Image,Height,Width){\*Код изменения размера*\}(NewImage)  \\Контейнер типа "PROCIMG" с начальным значением.

AC>> 2.Жизнеспособно ли это в принципе?
S>Без вводной части и обоснования всех введённых концепций/терминов — нет.
Мы работаем над этим

AC>> 4.Неявное приведение типов, насколько оно нужно?
S>It depends. Если под ним понимается возможность неявного приведения без потерь — из byte в int или из Time к DateTime (при условии явного объявления implicit cast operator) — пойдёт. Если имеется в виду, что корректность любого присваивания будет проверяться динамически, в рантайме — велкам к скриптовым языкам и прочей мелочи.
Именно возможность приведения без потерь. Вопрос в том покроет ли полиморфизм процедур/операторов эту возможность?

Здравствуйте, x-code, Вы писали:
XC>Вообще программирование "как создание электронных схем" — интересная тема. Все вроде бы не против, идея давно известна, но никто толком ничего в этой области не делает. Наверное, идея слишком далека от архитектуры современных компьютеров и операционных систем.
ИМХО проблема сегодня в том что она далека от классических принципов и методов разработка программ, и в чистом веде даёт преимущество лишь при решении некоторых задач.
В прошлом, во времена однопроцессорной архитектуры, она также была гораздо менее эффективна.
XC>1. Электронная схема работает вся сразу и одновременно. Каждый компонент — параллельный поток. Каждая часть компонента — параллельный поток. Каждый транзистор — тоже фактически параллельный поток, пусть и примитивный.
XC>В программах как правило один поток, ну два-три. Если это сервер, то потоков — по числу клиентов. Создание потоков — достаточно дорогая операция, и переключение между ними — тоже. А "электронно-компонентная" парадигма в идеале требует, чтобы каждая операция, каждый if и else был отдельным потоком.
Эта парадигма, это только абстракция, реализовать можно хоть на одном потоке(один раз созданном и работающем всё время работы программы), но конечно чем больше не псевдопаралельных потоков тем лучше.
XC>2. Электронная схема создается раз и навсегда. Она действительно "жесткая". В программе сущности появляются и исчезают динамически. К примеру, если в схеме есть, к примеру, 4 дешифратора, то их ровно 4 и не больше не меньше. Схема не может сама динамически подпаять себе еще парочку дешифраторов во время работы

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

Здравствуйте, samius, Вы писали:
S>электронные схемы — это скорее http://en.wikipedia.org/wiki/Flow-based_programming. Что именно у ТС — я не понял.
Это но в сплаве с императивным программированием, процедура может быть потоковой(поток данных) или императивной(поток инструкций),
императивные процедуры могут быть вызваны из потоковых и наоборот.

Здравствуйте, AlexCab, Вы писали:

AC>Здравствуйте, samius, Вы писали:
S>>электронные схемы — это скорее http://en.wikipedia.org/wiki/Flow-based_programming. Что именно у ТС — я не понял.
AC>Это но в сплаве с императивным программированием, процедура может быть потоковой(поток данных) или императивной(поток инструкций),
AC>императивные процедуры могут быть вызваны из потоковых и наоборот.

Это как?

Здравствуйте, AlexCab, Вы писали:

AC>Здравствуйте, samius, Вы писали:
S>>электронные схемы — это скорее http://en.wikipedia.org/wiki/Flow-based_programming. Что именно у ТС — я не понял.
AC>Это но в сплаве с императивным программированием,
Flow-based в общем случае не исключает императивное программирование, и давно с ним успешно сочетается.

AC>процедура может быть потоковой(поток данных) или императивной(поток инструкций),
Что такое процедура? В Flow-based есть понятие code component. Она не работает с потоком данных, она работает со значениями, поступающими из портов.
что за поток инструкций, какое отношение это имеет к императивному коду?
AC>императивные процедуры могут быть вызваны из потоковых и наоборот.

Здравствуйте, x-code, Вы писали:
AC>>процедура может быть потоковой(поток данных) или императивной(поток инструкций)
XC> Это как?
Код программы содержится в процедурах(они же значения-код из первого поста) и только в них.
"процедура" — когда речь идёт о представлении значения-кода как собственно кода(напр. "вызвать процедуру"),
"значение-код" — когда речь идёт о представлении процедуры как собственно значения(напр. "копировать значение-код").
Сам код это последовательность вызовов процедур(в императивной процедуре) или схема соединения вызовов процедур(вызов процедуры это и есть "code component")(в потоковой процедуре).
В императивной процедуре последовательно выполняется вызов за вызовом в порядке записи.
В потоковой процедуре значения поступают с входов(аргументов) "проходят через схему" и выходят через выходы(результаты). Вызов процедуры происходит когда на всех входах(аргументах) есть значение.
Вот например реализация процедуры которая суммирует свои аргументы:

 SUM CODE[INT,INT,INT,INT][INT]  \\Тип значений-кодов принимающих 4 аргумента и возвращающий один результат типа "INT" 

 S SUM(A,B,C,D){ \\Императивная процедура
               \\Код код суммирования("=>" - оператор копирования значения)  
                 A => T
                 T + B
                 T + C
                 T + D
                 T => R
                \\Определения
                 T INT 
               }(R)

 G SUM(A,B,C,D){| \\Потоковая процедура
                \\Схема суммирования("C1" и "C2" - перемычки).
                 (A,B)+(C1)
                 (C,D)+(C2)
                 (C1,C2)+(R)
                |}(R)

Можно представить потоковую процедуру так:

PS: !Ещё в разработке потому могут быть ошибки в концепции, синтаксисе, терминологии и т.п., не судите строго

Здравствуйте, AlexCab, Вы писали:

AC>Код программы содержится в процедурах(они же значения-код из первого поста) и только в них.
AC>"процедура" — когда речь идёт о представлении значения-кода как собственно кода(напр. "вызвать процедуру"),
AC>"значение-код" — когда речь идёт о представлении процедуры как собственно значения(напр. "копировать значение-код").
AC>Сам код это последовательность вызовов процедур(в императивной процедуре) или схема соединения вызовов процедур(вызов процедуры это и есть "code component")(в потоковой процедуре).
AC>В императивной процедуре последовательно выполняется вызов за вызовом в порядке записи.
AC>В потоковой процедуре значения поступают с входов(аргументов) "проходят через схему" и выходят через выходы(результаты). Вызов процедуры происходит когда на всех входах(аргументах) есть значение.
AC>Вот например реализация процедуры которая суммирует свои аргументы:
AC>

AC> SUM CODE[INT,INT,INT,INT][INT]  \\Тип значений-кодов принимающих 4 аргумента и возвращающий один результат типа "INT" 

AC> S SUM(A,B,C,D){ \\Императивная процедура
AC>               \\Код код суммирования("=>" - оператор копирования значения)  
AC>                 A => T
AC>                 T + B
AC>                 T + C
AC>                 T + D
AC>                 T => R
AC>                \\Определения
AC>                 T INT 
AC>               }(R)

AC> G SUM(A,B,C,D){| \\Потоковая процедура
AC>                \\Схема суммирования("C1" и "C2" - перемычки).
AC>                 (A,B)+(C1)
AC>                 (C,D)+(C2)
AC>                 (C1,C2)+(R)
AC>                |}(R)
AC>

AC>Можно представить потоковую процедуру так:
AC>

AC>PS: !Ещё в разработке потому могут быть ошибки в концепции, синтаксисе, терминологии и т.п., не судите строго

Что-то больно сложно. В Flow-based нужно просто соединить порты и забрать значение с некоторого выхода. никакого деления на императивные и потоковые процедуры там нет. Есть компоненты, которые работают только со своими входами/выходами.

Здравствуйте, samius, Вы писали:
AC>>Это но в сплаве с императивным программированием,
S>Flow-based в общем случае не исключает императивное программирование, и давно с ним успешно сочетается.
Truth.
AC>>процедура может быть потоковой(поток данных) или императивной(поток инструкций),
S>Что такое процедура? В Flow-based есть понятие code component.
У меня к понятию "code component" ближе вызов процедуры, а сама процедура это реализация "code component".
S>Она не работает с потоком данных, она работает со значениями, поступающими из портов.
Значения поступающие из портов это разве не поток данных?
S>что за поток инструкций, какое отношение это имеет к императивному коду?
То есть последовательное выполнение инструкций(возможно неправильно называть это так).
AC>>императивные процедуры могут быть вызваны из потоковых и наоборот.
S>

здесь

Здравствуйте, AlexCab, Вы писали:

AC>Здравствуйте, samius, Вы писали:

S>>Что такое процедура? В Flow-based есть понятие code component.
AC>У меня к понятию "code component" ближе вызов процедуры, а сама процедура это реализация "code component".
компонента это вызов, а процедура — реализация вызова? Что дает такой терминологический изыск?

S>>Она не работает с потоком данных, она работает со значениями, поступающими из портов.
AC>Значения поступающие из портов это разве не поток данных?
На сколько я себе представляю — не поток. Значения в портах — именно одиночные значения. Поступая в порты — они сбрасывают флаги либо форсируют вычисления на других концах коннекторов. Никаких потоков (в смысле как говорят о течении тока) там нет. Все вместе (весь граф) называют потоком, но природа происходящих процессов в нем чисто импульсная.
S>>что за поток инструкций, какое отношение это имеет к императивному коду?
AC>То есть последовательное выполнение инструкций(возможно неправильно называть это так).
Последовательное выполнение инструкций ничего не говорит об императивности. Ключевым фактором в императивности играет роль изменяемое состояние. Т.е. если последовательные инструкции изменяют некоторое внешнее по отношению к инструкциям состояние (живущее дольше чем выполняется инструкция), то это императив.

AC>>>императивные процедуры могут быть вызваны из потоковых и наоборот.
S>>

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

Здравствуйте, samius, Вы писали:
S>Что-то больно сложно. В Flow-based нужно просто соединить порты и забрать значение с некоторого выхода. никакого деления на императивные и потоковые процедуры там нет. Есть компоненты, которые работают только со своими входами/выходами.
Некоторые задачи проще/лучше решать в виде последовательности операций над значениями, другие в виде обработки потока значений, проходящего через операции. При реализации компонента(который работают только со своими входами/выходами, к которому нужно просто присоединить порты и забрать значение с некоторого выхода(в потоковой процедуре) или который нужно вызвать как подпрограмму(в императивной процедуре)) можно выбрать более подходящий способ. Затем при использовании компонента уже не будет иметь значения как он реализован:

\\Определения
 SUM CODE[INT,INT,INT,INT][INT]  \\Тип значений-кодов принимающих 4 аргумента и возвращающий один результат типа ";INT" 
 S SUM(A,B,C,D){A => T; T + B; T + C; T + D; T => R; T INT}(R) \\Императивная процедура
 G SUM(A,B,C,D){|(A,B)+(C1); (C,D)+(C2); (C1,C2)+(R)|}(R) \\Потоковая процедура
 J INT
\\Код(императивный)
 S(1,2,3,4) => J \\Вызов императивной процедуры, "J" = 10
 G(1,2,3,4) => J \\Вызов потоковой процедуры,"J" = 10

Здравствуйте, AlexCab, Вы писали:

AC>Здравствуйте, samius, Вы писали:
S>>Что-то больно сложно. В Flow-based нужно просто соединить порты и забрать значение с некоторого выхода. никакого деления на императивные и потоковые процедуры там нет. Есть компоненты, которые работают только со своими входами/выходами.
AC>Некоторые задачи проще/лучше решать в виде последовательности операций над значениями, другие в виде обработки потока значений, проходящего через операции. При реализации компонента(который работают только со своими входами/выходами, к которому нужно просто присоединить порты и забрать значение с некоторого выхода(в потоковой процедуре) или который нужно вызвать как подпрограмму(в императивной процедуре)) можно выбрать более подходящий способ. Затем при использовании компонента уже не будет иметь значения как он реализован:
AC>

AC>\\Определения
AC> SUM CODE[INT,INT,INT,INT][INT]  \\Тип значений-кодов принимающих 4 аргумента и возвращающий один результат типа ";INT" 
AC> S SUM(A,B,C,D){A => T; T + B; T + C; T + D; T => R; T INT}(R) \\Императивная процедура
AC> G SUM(A,B,C,D){|(A,B)+(C1); (C,D)+(C2); (C1,C2)+(R)|}(R) \\Потоковая процедура
AC> J INT
AC>\\Код(императивный)
AC> S(1,2,3,4) => J \\Вызов императивной процедуры, "J" = 10
AC> G(1,2,3,4) => J \\Вызов потоковой процедуры,"J" = 10
AC>

Кажись понял, потоковая процедура в своем объявлении декларирует не то как вычислить результат, а то как связан результат со входами в терминах компонент, т.е. это даже не процедура, а именованный кусок схемы. Верно?
Если да, то имхо, термин "потоковый" в сочетании "процедура" тут затрудняет понимание.

Здравствуйте, samius, Вы писали:

S>Кажись понял, потоковая процедура в своем объявлении декларирует не то как вычислить результат, а то как связан результат со входами в терминах компонент, т.е. это даже не процедура, а именованный кусок схемы. Верно?
S>Если да, то имхо, термин "потоковый" в сочетании "процедура" тут затрудняет понимание.

Спасибо, теперь и я понял.
Идея неплохая, надо будет подумать, как ее можно грамотно интегрировать в современный и понятный большинству язык программирования. Вообще почитать-бы что-то по dataflow programming...

Здравствуйте, x-code, Вы писали:

XC>Здравствуйте, samius, Вы писали:

S>>Кажись понял, потоковая процедура в своем объявлении декларирует не то как вычислить результат, а то как связан результат со входами в терминах компонент, т.е. это даже не процедура, а именованный кусок схемы. Верно?
S>>Если да, то имхо, термин "потоковый" в сочетании "процедура" тут затрудняет понимание.

XC>Спасибо, теперь и я понял.
XC>Идея неплохая, надо будет подумать, как ее можно грамотно интегрировать в современный и понятный большинству язык программирования. Вообще почитать-бы что-то по dataflow programming...
Можно покурить maya api, правда оно старенькое, может чего покрасивше есть...

Здравствуйте, samius, Вы писали:
S>Кажись понял, потоковая процедура в своем объявлении декларирует не то как вычислить результат, а то как связан результат со входами в терминах компонент, т.е. это даже не процедура, а именованный кусок схемы. Верно?
Да, но только не именованный, как лямбды. Можно, по аналогии, сравнить "контейнер" с программируемым контролером в котором можно динамически менять прошивку.
Например, работу следующего кода:

  \*Имя_типа*\ CODE [\*Типы_рагументов/входов*\][\*Типы_результатов/выходов*\] \*Значение_по_умолчанию*\   \\Формат определения типа
  \*Имя_контейнера*\ \*Имя_типа*\ \*Начальное_значение(если_не_задано_будет_по_умолчанию)*\                \\Формат определения контейнера

            Name SomeType (){ 
                             \\Определения 
                              ARH CODE [INT,INT,INT][INT] (){}() \\Тип для значений-кодов
                              S ARH \\Контейнер для значений-кодов типа "ARH"
                             \\Код(императивный)  
                              \\Значение-код типа "ARH", императивная процедура                                                                  
                              (A,B,C){
                                     \\Определения 
                                      J INT 
                                     \\Код(императивный) 
                                      A + B => J
                                      J + C => R
                                     }(R)ARH => S \\Помещение в контейнер "S" значения типа "ARH"
                              \\Вызов значения в контейнере "S"         
                              S(1,2,3) => R1   
                              \\Значение-код типа "ARH", потоковая процедура        
                              (A,B,C){|
                                     \\Определения 
                                      AD CODE [INT,INT,INT,INT][INT] (){}() \\Тип для значений-кодов
                                      MySum AD (A,B,C,D){| 
                                                        \\Код(потоковый)
                                                         (A,B)+(C1)
                                                         (C,D)+(C2)
                                                         (C1,C2)+(R)
                                                        |}(R) \\Контейнер для значений-кодов типа "AD", с начальным значением
                                     \\Код(потоковый) 
                                      (A,B)-(J1) 
                                      (A,B,C,J1)MySum(R)
                                     |}(R)ARH => S \\Помещение в контейнер "S" значения типа "ARH"   
                              \\Вызов значения в контейнере "S"               
                              S(5,4,3) => R2        
                             }(R1,R2)

Можно представить так:

Здесь архив с раскадровкой и комментариями.

Здравствуйте, samius, Вы писали:

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

Да? А я вот затрудняюсь обычно четко сформулировать... Например, как назвать атомарное изменение состояния у целой схемы? Вот возьмем моделирование аналоговой схемы через численное интегрирование в координатах времени. Каждый вычислительный узел — двухтактный. Во время первого такта модель вычисляет значения на выходах всех компонент, но сами эти значения на выход не подает, поэтому вычисления состояний связанных компонент можно смело распараллелить. На втором такте предвычисленные значения компонент просто подаются на выход и используются для следующей итерации вычисления. Сам процесс вычисления значения внутри каждого модуля может так же быть циклическим (т.е. выполнять более подробное интегрирование), где каждый цикл опять же двухтактный.

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

От:	AlexCab	LinkedIn
Дата:	20.08.11 11:34
Оценка:

	От:	Sinix
	Дата:	20.08.11 12:02
	Оценка:

	От:	x-code
	Дата:	20.08.11 17:56
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	21.08.11 06:14
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	21.08.11 07:05
Оценка:

	От:	vdimas
	Дата:	27.08.11 13:08
	Оценка: