alternative to "hot" inputs - Flow Based Programming

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion alternative to "hot" inputs
Date: Tue, 14 Aug 2012 10:36:08 -0700 (PDT)
From: Dan <dpolo...@gmail.com>
To: flow-based-programming@googlegroups.com
Message-Id: <4ff8426e-9394-441a-9552-e7d6374cba36@googlegroups.com>
In-Reply-To: <9b34037c-4435-4ac0-9acf-d679478c1897@googlegroups.com>
References: <a319af1e-0222-4145-a391-36895313bac7@googlegroups.com> <CACtVJg_CKG9K=RKOvroFp3GxgDD6+40SqKfTCRM7d94KVbp2cA@mail.gmail.com> <5021C7FC.7060202@rogers.com> <50228D9F.9060404@rogers.com> <50245B38.1080706@rogers.com> <CAAOQMSt2fGo4ojOOAUJ4OPGY=d=anep=qvD9XDt6Cv=DvgEZWw@mail.gmail.com> <1344717693.50538.YahooMailNeo@web88512.mail.bf1.yahoo.com> <CAAOQMSua5VCnOo_MHB+cosGFbEmEErFXUGG8eK9T_kV7sfT43w@mail.gmail.com> <502815EF.2050409@rogers.com> <57f02494-d944-4d84-a559-ba490b24a26b@googlegroups.com>
 <502A57C7.7070305@rogers.com>
 <9b34037c-4435-4ac0-9acf-d679478c1897@googlegroups.com>
Subject: Re: alternative to "hot" inputs
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_344_25970126.1344965768560"

------=_Part_344_25970126.1344965768560
Content-Type: multipart/alternative; 
	boundary="----=_Part_345_3872711.1344965768561"

------=_Part_345_3872711.1344965768561
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

It seems it is very hard for almost all the programmers here interested in 
FBP to translate from a pure declarative FBP language (data flow driven) to 
an imperative language like the assembler (control flow driven).

In the end it is the only way and there is a form of equivalence. But if 
you mix and interpose other languages as middleware between a hypothetical 
FBP declarative language and assembler then everything becomes bloated.

I would be very interested to discuss the translation process from a simple 
FBP program (diagram) to a simple ASM program. The process itself 
(compilation) is an FBP program. The binary code is data that flows from 
memory into the microprocessor and back to the memory. Everything is data 
flow based in the end but it is hard to find the common picture and the 
transformation from one state (FBP declarative source code, text or 
diagram) into the other state/form of existence (binary code).

In fact we have to replace all the components from the diagram with data in 
the memory. Part of this is data as we know it (floats, ints etc.) some 
other part is data as opcodes. The links/connections are represented also 
as data but also as opcodes. The result is a representation of the FBP 
diagram but it is not one-to-one representation because the compiled code 
could depend on the number of processors and the diagram is "stretched" 
into a single thread control flow based.

If this is a subject of interest I will create a new topic.

Dan

------=_Part_345_3872711.1344965768561
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

It seems it is very hard for almost all the programmers here interested in =
FBP to translate from a pure declarative FBP language (data flow driven) to=
 an imperative language like the assembler (control flow driven).<br><br>In=
 the end it is the only way and there is a form of equivalence. But if you =
mix and interpose other languages as middleware between a hypothetical FBP =
declarative language and assembler then everything becomes bloated.<br><br>=
I would be very interested to discuss the translation process from a simple=
 FBP program (diagram) to a simple ASM program. The process itself (compila=
tion) is an FBP program. The binary code is data that flows from memory int=
o the microprocessor and back to the memory. Everything is data flow based =
in the end but it is hard to find the common picture and the transformation=
 from one state (FBP declarative source code, text or diagram) into the oth=
er state/form of existence (binary code).<br><br>In fact we have to replace=
 all the components from the diagram with data in the memory. Part of this =
is data as we know it (floats, ints etc.) some other part is data as opcode=
s. The links/connections are represented also as data but also as opcodes. =
The result is a representation of the FBP diagram but it is not one-to-one =
representation because the compiled code could depend on the number of proc=
essors and the diagram is "stretched" into a single thread control flow bas=
ed.<br><br>If this is a subject of interest I will create a new topic.<br><=
br>Dan<br>
------=_Part_345_3872711.1344965768561--

------=_Part_344_25970126.1344965768560--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
