ИР>Есть немного

ИР>Но ты же просил подходы. Вот тебе и такой подход.

-module( node ).

new() -> nil.

cycle( _ ) ->
    out( c, in( a ) + in( b ) ),
    nil.

connect( Source, Out, Destination, In )

%% receive message on specified input
in( Name ) -> 
    put( [ Name | get( inputs ) ] ),
    receive { Name, Msg } -> Msg end.

%% 
out( Name, Msg ) ->
    case get( Name ) of
        undefined -> not_connected;
        [ touched | Subscribers ] -> bcast( Msg, Subscribers );
        Subscribers ->     bcast( Msg, Subscribers ),
                        put( Name, [ touched |Subscribers ] )
    end.

%% broadcast message to the list of subscribers
%%% send message w/o translation
bcast( Msg, [ { Proc, In } | T ] ) ->
    Proc ! { In, Msg },
    bcast( Msg, T );
%%% send message with translation
bcast( Msg, [ { Proc, In, F } | T ] ) ->
    Proc ! { In, F( Msg ) },
    bcast( Msg, T );
%%% send empty message (bubble) and ignore translation
bcast( nil, [ { Proc, In, _ } | T ] ) ->
    Proc ! { In, nil },
    bcast( Msg, T );
%%% exit 
bcast( _, [ undefined ] ) -> ok.

G>-module( node ).

G>new() -> nil.

G>cycle( _ ) ->
G>    out( c, in( a ) + in( b ) ),
G>    nil.
G>

G>connect( Source, Out, Destination, In )
G>

G>где имена входов и выходов — атомы. Что, впрочем, не обязательно .

  fun {GateMaker F}
    fun {$ Xs Ys}
      fun {GateLoop Xs Ys}
        case Xs#Ys of {X|Xr}#{Y|Yr} then {F X Y}|{GateLoop Xr Yr} end
      end
    in
      thread {GateLoop  Xs Ys} end
    end
  end
   
  AndG = {GateMaker fun {$ X Y} X*Y end}
  OrG  = {GateMaker fun {$ X Y} X+Y-X*Y end}
  XorG = {GateMaker fun {$ X Y} X+Y-2*X*Y end}

  % Теперь можно описать схему состоящую из нескольких элементов. Например сумматор. Он имеет три входа и два выхода.
  proc {FullAdder X Y Z ?C ?S}
    K L M
  in
    K = {AndG X Y}
    L = {AndG Y Z}
    M = {AndG X Z}
    C = {OrG K {OrG L M}
    S = {XorG Z {XorG X Y}}
  end

  % Использование
  declare
  X=1|1|0|_
  Y=0|1|0|_
  Z=1|1|1|_
  {FullAdder X Y Z C S}
  {Browse inp(X Y Z)#sum(C S)}

A = 10
B = 20
C = B + A
D = C + A
{Browse D}

B = 20
thread D = C + A end
thread C = B + A end
A = 10 
{Browse D}

fun {Spawn P}
PId in
  thread
    PId={Thread.this}
    {Thread.suspend PId}
    {P}
  end
  PId
end

proc {Resume Id}
  {Thread.resume Id}
  {Thread.suspend {Thread.This}}
end

G>>>Понятно — похоже, что никто .

G>Плюс, — сейчас у меня в модели нет тактовой частоты, она асинхронна. А что, если я захочу сделать схему тактированной (вполне вероятно, кстати)? В Эрланге это — без проблем, я спущу тактовую частоту вниз по иерархии процессов-функциональных блоков, спрятав всю обработку (или ее часть) во фреймворк. Что будет с Моцартом? Я имею в виду — не придется ли там докручивать сопоставимого размера (гхм — ну строк 100-150 ) фреймворк? И где тогда бенефит?

fun {Clock}
  fun {Loop B}
    {Delay 1000} B | {Loop B}
  end
in
  thread {Loop 1} end
end

%собствеено элемент - задержка
fun {DelayG Xs}
  0|Xs
end

%а это модель двухстабильного триггера
fun {Latch C DI}
  DO X Y Z F
in
  F={DelayG DO}
  X={AndG F C}
  Z={NotG C}
  Y={AndG Z DI}
  DO={OrG X Y}
  DO
end

G>500 — мало, столько тредов оперсистема держит без проблем. Я бы проверил на чем-нибудь реальном — например, тысяч эдак 10000. Правда, тогда список был бы практически пуст , у большинства было бы error или timeout.