WiseGeek

[Paul Morrison]

Thought you might be inetrested in WiseGeek's description of FBP:

http://www.wisegeek.com/what-is-flow-based-programming.htm

[Dan]

The description is good and interesting but there is one phrase that needs more clarification:
"A single port can relate to several instances of a single component, making the structure easy to use on a distributed system or for parallel processing."

At first glance it seems that the "single component" is used as a model and "called" from different places like an usual function. It is interesting if the author had in mind also the (functional) components with state or not. Also it would be interesting to know how a single component could be used through a single port and relate to several instances. The author does not mention if that port is owned by that single component or by a mother component.

I have used the term "called" (between quotes)  because in FBP the functional components are not exactly called but we just send IPs (parameters) to them. In FBP we have to think to a way to reuse the "code" of a component exactly in the same manner a classical function is reused each time is called from different places.

In the end, in FBP terms, each place of call is another instances of a (functional) component. Is this what the author had in mind? If yes, how it is implemented? Classically, a function uses the call stack mechanism for this but FBP is "stackless" or at least is not using the same mechanism of "call".

What do you think?

Regards,
Dan

[Michael IV]

Are you Paul Morrison, the author of the flow based programming book?  Sorry for the question, I am the first time here.

[Tom Young]

I am not Paul and neither is this GoogleGroup, but the Paul Morrison, to whom you refer, did create this group and is the same person who contributes the most to it and who led off this thread about the WiseGeek FBP description. 

Welcome to the group!

      Cheers,

              -Tom

--
"...the shell syntax required to initiate a coprocess and connect its input and output to other processes is quite contorted..."
W. Richard Stevens [Advanced Programming in the Unix Environment, p441]

[Paul Morrison]

Hi Michael,

Sorry I didn't see your question! Yes, I'm that Paul! Welcome
aboard! It looks like you are into some interesting stuff - perhaps
you could tell how (or if) FBP might tie into it...?

[Paul Morrison]

On Jan 17, 1:24 pm, Dan <dpolo...@gmail.com> wrote:
> The description is good and interesting but there is one phrase that needs
> more clarification:
> "A single port can relate to several instances of a single component,
> making the structure easy to use on a distributed system or for parallel
> processing."
>

Yes, I was curious about that phrase too! I have put a post on
wiseGeek asking if they want to participate in a discussion - not sure
if they would be interested...

I know what you mean by "stackless", but I have tended to think of FBP
as having multiple stacks - at least that's the way I've built all my
implementations so far. But, certainly, at least "subroutine-like"
components (non-loopers) can probably share stacks (if it's worth the
trouble)...

You also say, "In FBP we have to think to a way to reuse the "code" of

a component exactly in the same manner a classical function is reused

each time is called from different places. " Since component code is
what used to be called read-only, I don't see this as a problem... do
you?

[Tom Young]

Dynamic reuse of executable code requires, as you probably know, that it be 're-entrant'.  The GCC compiler  includes a 're-entrant' attribute, however, it is up to the developer, I believe, to
verify the attribute.  Reentrancy is more or less attainable, depending on the platform.  The Prime Computer was designed so that all code was re-entrant. 

HTH.

             -Tom

--
Tom Young
47 MITCHELL ST.
STAMFORD, CT  06902

"When bad men combine, the good must associate; ..." 
   -Edmund Burke 'Thoughts on the cause of the present discontents' , 1770

This e-mail message from Tom Young is intended
only for the individual or entity to which it is addressed. This e-mail
may contain information that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the intended recipient,
you are hereby notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you received this
e-mail by accident, please notify the sender immediately and destroy
this e-mail and all copies of it.

[Paul Morrison]

On Jan 19, 7:08 pm, Tom Young <twy...@twyoung.com> wrote:
> On Wed, Jan 18, 2012 at 4:38 PM, Paul Morrison <paul.morri...@rogers.com>wrote:
>  ... Since component code is

> > what used to be called read-only, I don't see this as a problem...  do
> > you?
>
> Dynamic reuse of executable code requires, as you probably know, that it be
> 're-entrant'.  The GCC compiler  includes a 're-entrant' attribute,
> however, it is up to the developer, I believe, to
> verify the attribute.  Reentrancy is more or less attainable, depending on
> the platform.  The Prime Computer was designed so that all code was
> re-entrant.
>

I assume we're agreeing :-) You're right about reentrancy being a
requirement. The read-only attribute is even more stringent than
reentrant (certain weird things allowed in reentrant are not allowed
in read-only), and really no harder to write! The IBM CICS on-line
environment only required reentrancy, but I just found it easier just
to stay read-only!

[Dan]

Quote from Paul Morrison:

"You also say, "In FBP we have to think to a way to reuse the "code" of

a component exactly in the same manner a classical function is reused

each time is called from different places. "  Since component code is

what used to be called read-only, I don't see this as a problem...  do

you?" [end quote]

Yes, I don't see this as a problem. I just "translated" the classical "function call" aspect into FBP term: a classical function call is translated in FBP terms into an instance (component realization) of a model (function). It seems many don't realize that a function call is in fact a new instance into that place (of call).
Instead many programmers think in the following terms: my parameters (messages) are sent into a function (singleton) that is doing the job and it sends back the results. But the FBP implementation should make use of the code that is common to all "calls" i.e. instances. This is not quite obvious.
For instance many programmers when think about a function think to code only. Function is not just code it could be data. These data is shared i.e. part of the model. In fact I don't see a big difference between data and functions in FBP. All of them are components (more functional, more data or mix).

Quote from Paul Morrison:

"I assume we're agreeing :-)  You're right about reentrancy being a
requirement.  The read-only attribute is even more stringent than
reentrant (certain weird things allowed in reentrant are not allowed
in read-only), and really no harder to write!  The IBM CICS on-line
environment only required reentrancy, but I just found it easier just

to stay read-only!" [end quote]

I don't like too much these kind of flags in FBP. If something is read only then it should have no input ports, so it could not be modified but only read. Is that simple. Something that is reused i.e. is common (e.g. a function) is a component that is only read. This is translated into: the code is executed but not modified. But this code that is executed is like being a duplication in the place of call but factorized in the place of function definition (model).

A function is called reentrant if it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete executing (from Wikipedia). It means the function (read only / model) should not rely on any internal state variables. These state variables should be part of the particular call i.e. instance. In classical languages all these variables are saved on the stack (the only one stack unfortunately). In FBP all these particular variables are part of the place of call i.e. instance. You might say that it resembles with OOP where all particular state variables are members into an object. Yes it does. In OOP the member variables exceed the life of stack variables. The stack is a temporary equivalent of the object state variables from OOP used to save the variables from "connections". Do not forget that the connection itself is a state variable (or a full stack if you want to implement queues).

The main idea is to separate what is common from what is specific. What is common is reused as read only models. A function is a read only model i.e. a FBP component with no input ports. Now you might say: oh, a function is a component with no input ports? So how we deliver the IPs (parameters)? Well you don't deliver the parameters to the function (model) but to its instances ("place of call" remember?). You deliver the IPs to another component that is a kind of duplication of the function (model). You send the parameters to an instance not to the model (function definition). The call stack mechanism is used in classical languages to implement exactly that: separate the instance parameters (saved on the stack) from what is common (function code). In FBP you should have a one way connection from the model (the function code in our case) to all its instances ("place of calls" in classical terms).

Unfortunately I have not seen too many strong ideas regarding the implementation of these aspects in FBP and it seems there still is confusion regarding this subject.

Start with this main issue in mind: if something is read only then it should have no input ports. This should trigger the next question: how this "something" is used in the FBP network? From now on a next set of questions and answers will pave your implementation solution.

[Michael IV]

Hi Paul.Thank you .I ordered your book and waiting forward reading it.Well, I deal with tools programming for 3D engines.Currently doing it based on Asobe Flash Platform.Using ActionScript 3.0   .I have a kind of dumb question .Reading the posts here I can see that the FBP is mostly being related to multi-threading tasks.So is your book directed to multi-threaded implementations  and  implies that the used platform allows multi-threading?In my case I started looking for a way to write an app where you can edit shader programs in real time using visual nodes with connectors.The best examples for this are UDK (Unreal Engine) Kismet/Material editors or VisualStudio 2011 HLSL editor. In Flash you have a single thread.So is your book helpful to build a single threaded application that implements FBP paradigm ? Again ,sorry ,may be I had to start reading the book first before asking it all :) 

Regards ,

Michael  

--

Michael Ivanov ,Senior Programmer
Neurotech Solutions Ltd.
www.neurotechresearch.com
http://blog.alladvanced.net
Tel:054-4962254
mic...@neurotech.co.il
te...@neurotech.co.il

[Paul Morrison]

On Jan 23, 5:20 am, Dan <dpolo...@gmail.com> wrote:

> For instance many programmers when think about a function think to code
> only. Function is not just code it could be data. These data is shared i.e.
> part of the model. In fact I don't see a big difference between data and
> functions in FBP. All of them are components (more functional, more data or
> mix).

...
> I don't like too much these kind of flags in FBP. *If something is read
> only then it should have no input ports*, so it could not be modified but

> only read. Is that simple. Something that is reused i.e. is common (e.g. a
> function) is a component that is only read. This is translated into: the
> code is executed but not modified. But this code that is executed is like
> being a duplication in the place of call but factorized in the place of
> function definition (model).
>

Dan, there seems to be some fundamental misunderstanding here. Your
statement *If something is read-only then it should have no input
ports* makes no sense in the FBP context. I do remember that, when I
first started lecturing about FBP, some programmers seemed to have
trouble with the concept of multiple processes sharing code, so I used
the analogy of a bunch of people standing reading a notice on a notice
board: provided none of them are modifying the notice, they can
proceed totally independently at their own speed. Problems only arise
if one or more of them tries to modify the notice. Most programs will
have a certain amount of read-only data - e.g. 0, 1, size of a table,
etc. - this can of course be treated as part of the program.
Modifiable data is either specific to an instance of the component (a
"process" - see below) or it is "out there" in an IP (information
packet), or on a database. There is no confusion. And, yes, as I
said elsewhere, all my implementations so far have used a separate
stack per process.

If you have the 2nd edition of my book, you will see that I had a lot
of trouble settling on a term for "unit of concurrency" (i.e. instance
of a read-only code component), and settled on the word
"process" (which *is* used by Erlang!). The preface to the 2nd
edition gives a list of terms that I have come across in the
literature - I rather like "vat" (E) and "island" (Tweak)! Just as we
have "component" for the code and "process" for the thing that
executes the component asynchronously, we actually need to distinguish
"connection point" (point where a connection *could* make contact with
a component, and "port" (point where process makes contact with a
process). In point of fact, it doesn't seem to be confusing to use
the term "port" interchangeably, but they *are* different. Hope this
helps!

[Paul Morrison]

Hi Michael,

Not a dumb question! I stumbled across FBP when looking for a better
way to develop applications, and rapidly found that while it was great
for building applications, it was even more powerful for maintaining
them (or as Ralf calls it, evolving them). The big breakthrough was
getting away (mentally, at least) from the von Neumann paradigm of a
single instruction counter and uniform array of memory cells. FBP
didn't really take off for many years, but we now have multiprocessor
machines, grid, networking, etc., and more and more people seem to be
discovering that FBP is a great paradigm for building applications in
this kind of environment. I fully admit that I am probably not up to
date on the latest hardware and software, but people who are seem to
be getting excited about FBP, so I think maybe it is starting to take
off! I also know nothing about shaders, but hopefully you will find
stuff in the book that ties into your work. It would be great if at
some point you could share some of your work with us!

On Jan 19, 2:49 am, Michael IV <explomas...@gmail.com> wrote:
> Hi Paul.Thank you .I ordered your book and waiting forward reading it.Well,
> I deal with tools programming for 3D engines.Currently doing it based on

> Adobe Flash Platform.Using ActionScript 3.0   .I have a kind of dumb

[ern0]

(I'm trying to pick up the line, I've some hundred unread letters from
the list.)

> Reading the posts here I can see that the FBP is mostly being related
> to multi-threading tasks.So is your book directed to multi-threaded
> implementations and implies that the used platform allows
> multi-threading?In my case I started looking for a way to write an
> app where you can edit shader programs in real time using visual
> nodes with connectors.

Flow-based systems requires no multithreading environment or
architecture, if the task does not require it.

I've written a dataflow engine in C++ for automation (with a friend of
mine), it has very weak support for multithreading, but there's no
problem, because the domain requires no multithreading at all. You press
a button or a timer counts down, it goes thru some components, which
decide what should happen, then, finally a lamp turns on. All the things
must be quick, when I press a button, the lamp must be turned on
immediatelly. Maybe it would be /slower/ with multitask, because of the
scheduler overhead. Now components call each other, with compile-time
binded function call, like normal C/C++ functions do.

Some cases multithreading can be advantage. A nice example is Unix pipes
vs MS-DOS pipes: Unix systems runs piped commands parallel, passing data
with the help of special FIFO "files", while MS-DOS runs commands one by
one, collecting one command's output to a tmp file, which will server as
input for the next command. Both works, and there are cases, where
MS-DOS peroforms no worse than Unix, e.g. if there's only a file reader
and a single sort in the chain (the whole file must be read in order to
sort it): cat (or type) names.txt | sort.
--
ern0
dataflow programmer