Chapter 7 Composite Components -- How?
rlewis
Here is how I am using my terms to say my assumptions and ask my
question:
An elementary processing unit (EPU) is a processing unit (PU) coded in
a non-FBP methodology. The reason to have EPUs is that initially, no
PUs exist, and FBP depends on the existence of PUs.
A _composite_ processing unit (CPU) is a processing unit created using
FBP methodology. FBP methodology creates new CPUs by connecting PUs
using FBP mechanisms of creating, sending, receiving, altering, and
dropping Information packets (IPs).
Seems like we are supposed to be able to connect EPUs into a CPU so
that the CPU looks exactly like an EPU. A CPU can be connected with
other CPUs or EPUs using the same FBP mechanisms mentioned to create
more CPUs. CPUs are supposed to become black boxes that we can use
from simple documentation descriptions. We do not trouble ourselves to
inspect or understand the internals of CPUs.
The ability to create new CPUs is important for structural
decomposition of a programming problem.
I feel I understand conceptually. However, I do not see how to make
CPUs that I can think of as single PUs instead of a sub-network of FBP
EPUs. That is my question: How do we make the CPUs into black boxes?
Does a CPU become an executable (Windows *.exe file)? Or is there some
kind of *.fbp file that has an IP and flow description language that
connects *.exe files and *.fbp files? Seems that one way or another a
new CPU needs to be assigned a name or number. And thereafter it is
referred to by its name or number. Maybe the name is a file name or a
function name?
Is my question understood? Any explanations or examples?
Paul Morrison
we certainly need to be able to make them black boxes as far as their
users are concerned. However, this question seems to be more
implementation-oriented. I assume that you are referring to C(++)
implementations - and the question would apply to my (or anyone
else's) implementation. However, in my own case, you are ahead of
me! What I would assume is that I can turn a subnet into a DLL, and
load it at run time, or link it statically with the rest of the
network, but I won't be able to answer you for sure until I try! In
the case of JavaFBP and C#FBP, subnets work pretty much the way you
describe (they have annotations just like EPUs), but I don't know how
to make them truly "black" in the Java or C# environment! Anyone
else?
Paul Morrison
On Nov 10, 12:36 pm, Paul Morrison <paul.morri...@rogers.com> wrote:
> I don't know how
> to make them truly "black" in the Java or C# environment!
equivalent...?
Ralf Westphal
don´t need to be expressed in 3GL source code at all.
The work horses are operations/processes, the leafs of a hierarchy of
flows.
They need to have a certain form like C# function or Java class; maybe
they even need to derive from some FBP base class.
Flow, though, can be expressed as simple tables. Take this example:
http://bergie.iki.fi/blog/archive/month/2011/8/
As a table it could read:
.In, ReadFile.In
ReadFile.error, Output.in
ReadFile.out, SplitStr.in
SplitStr.out, Counter.in
Counter.count, Output.in
And I mean it: that´s the description of the network and could be
passed to a FBP engine in addition to the operations ReadFile etc.
Now on to composites. How about refining ReadFile: first the file is
opened, then all lines are read.
ReadFile
.in, OpenFile.in
OpenFile.out, ReadLines.in
ReadLines.out, .out
OpenFile.error, .error
ReadLines.error, .error
This also could be passed to a FBP engine; it would then automatically
recognize ReadFile in the first network description as a composite. Or
some "container" could read this from a text file or an embedded
resource in a library.
It´s just two languages we need: one for operations (the platform
language), one for networks (a general FBP language).
But if you don´t want to interpret multiple tables you can put both
descriptions in one:
.In, ReadFile/OpenFile.In
ReadFile/OpenFile.out, ReadFile/ReadLines.in
ReadFile/ReadLines.out, SplitStr.in
ReadFile/OpenFile.error, Output.in
ReadFile/ReadLines.error, Output.in
SplitStr.out, Counter.in
Counter.count, Output.in
That way a composite can be reused in different contexts. And still
only operations need to be implemented in a 3GL: OpenFile, ReadLines,
SplitStr, Counter, Output.
Paul Morrison
On Nov 10, 1:25 pm, Ralf Westphal <ralf...@googlemail.com> wrote:
> It all depends on how you describe flows. In my view flows (networks)
> don´t need to be expressed in 3GL source code at all.
3GL (I assume this includes Java) has come into the discussison is
because some people like to stay in one language both for the network
definitions and for the EPUs as Ron calls them.
>
> As a table it could read:
>
> .In, ReadFile.In
> ReadFile.error, Output.in
> ReadFile.out, SplitStr.in
> SplitStr.out, Counter.in
> Counter.count, Output.in
>
> And I mean it: that´s the description of the network and could be
> passed to a FBP engine in addition to the operations ReadFile etc.
By the way, Henri and Ralf, in FBP this diagram does not guarantee
that the count is displayed _after_ the records. When two output
ports are connected to one input port, the streams are merged on a
first-come, first-served basis. If you really want to have all the
first stream, followed by all of the second stream, etc., you should
use a component like CONCAT. If in your testing, the count actually
followed the records, this was pure chance, and cannot be relied on!
If you decide you want the default to be sequential, rather than
intermixed, then you give up an important technique for improving
program elapsed time.
> Now on to composites. How about refining ReadFile: first the file is
> opened, then all lines are read.
>
> ReadFile
> .in, OpenFile.in
> OpenFile.out, ReadLines.in
> ReadLines.out, .out
> OpenFile.error, .error
> ReadLines.error, .error
>
> This also could be passed to a FBP engine; it would then automatically
> recognize ReadFile in the first network description as a composite. Or
> some "container" could read this from a text file or an embedded
> resource in a library.
"mother" process? In JavaFBP and C#FBP, these are SubIn and SubOut,
respectively.
> It´s just two languages we need: one for operations (the platform
> language), one for networks (a general FBP language).
>
> But if you don´t want to interpret multiple tables you can put both
> descriptions in one:
>
> .In, ReadFile/OpenFile.In
> ReadFile/OpenFile.out, ReadFile/ReadLines.in
> ReadFile/ReadLines.out, SplitStr.in
> ReadFile/OpenFile.error, Output.in
> ReadFile/ReadLines.error, Output.in
> SplitStr.out, Counter.in
> Counter.count, Output.in
>
> That way a composite can be reused in different contexts.
an example of this in http://www.jpaulmorrison.com/fbp/image010.jpg .
The two blocks marked INFQUEUE are both subnets - and can be seen
(using a slightly different notation) in http://www.jpaulmorrison.com/fbp/Fig15.5.gif
. Note that the two instances of this subnet are running
asynchronously with each other... as you would expect.
> only operations need to be implemented in a 3GL: OpenFile, ReadLines,
> SplitStr, Counter, Output.
rlewis
current state of FBP knowledge and thinking. I repeat some things
posted elsewhere. Thus, I hope readers do not need to search much the
other posts to figure out what I mean by CPU and everything else.
> don´t need to be expressed in 3GL source code at all.
expressed in source code at all.
Even so, I feel I need some kind of mapping of FBP diagram to source
code. The mapping is essential to make FBP useful, because in the end
a running program or system of running programs must result. I suppose
that many mappings are possible.
Composite Processing Unit (CPU) can map to a DLL. A DLL can glue
Elementary Processing Units (EPUs) and CPUs into a new CPU. I think if
you can map to a DLL, you can also map to an EXE (executable file) or
a BAT (a DOS/Windows batch file).
BATs are interesting. The input is in the command line. Inside the
BAT, the inputs are represented as %1 for the first argument, %2 for
the second argument, %3 for the third argument of the command line,
etc. And the Processing Units (PUs) inside the file can be EPUs (EXE
files) or CPUs (other BATs). And further, inside the BAT the PU is
listed with its inputs (the %1, %2, etc.). The outputs are not listed,
though.
Instead of the mapping using BATs I just described, you can let a
function (be it a C, C++, C#, or other function) be the PU. The body
of the function being in a precompiled and included DLL makes the
function (the PU) a black box. It is a black box because we cannot
inspect the source code of the PU. Therefore, we are forced to rely on
a simple description of the function PU's use.
I close my eyes for a few moments to block out reality. I visualize in
my reverie whatever I wish FBP to be. And I wish FBP to be the elusive
silver-bullet that will make developing source code quick and easy,
regardless of how simple or complex the programming problem. I wish it
to be an analysis tool that leads me reliably to a reasonable solution
to any programming problem, from parsing strings, to sorting results,
to formatting financial statements, to anything, just anything at
all.
FBP should deliver the accelerated software development that object
oriented design and object oriented programming promised but did not
delivered. I think that structured, top-down design and programming
delivered accelerated software development, but bogs down when the
system becomes too large. Object oriented methodology enabled us to
manage the complexity of large and otherwise unwieldy programs.
Functional programming also promised greatly accelerated programming.
But pure functional programming is not able to stand on its own. It
lacks a way to get data in and a way to get data out of functions.
Functional programming uses monads for such things as input and
output. And monads are functions that are allowed to violate tenets of
pure functional programming methodology, such as the "no side effects"
rule. Output monads necessarily have a side-effect, by definition.
Seeing an accounting system or a database system in terms of a
functional methodology is difficult. Such systems change states. And
pure functional programming methodology eschews states.
I open my eyes. And now I continue my reverie staring blankly into the
air.
On the other hand, Flow Based Programming (FBP) seems to allow me to
manage the complexity of arbitrarily large and complex systems. FBP
even simplifies what would otherwise be a complex system. There is no
particular limit to creating composite PUs, each CPU being a subnet of
PUs. The fundamental key seems to be to change our thinking. OO
required changing our thinking. FBP also requires changing our
thinking. Instead of thinking of objects, instead of thinking of
things, we think of Information Packets (IPs). Instead of following
the path of processing, we follow the path of data (IPs).
An IP may look like a struct in C or a class in C++, C#, or Java. It
can even look like a "function" in Javascript--but of course in
Javascript, the keyword 'function' has different semantics from
'function' of other languages.
I see FBP as simple enough to learn and use quickly. It is mainly how
to change our thinking to follow the flow of data from creation from
outside the system or within a processing unit, through the data
transformations, to dropping in a processing unit or exporting to
outside the system.
I can be a Flow Based Programming extremist and purist. In which case,
I devise an EPU for every assembly instruction of my computer. From
then on, I never have to look at assembly. I look at EPUs. I change my
mind. I will represent everything I can do in C language as a set of
EPUs. I can still program anything. But C will be fewer elements to
create and C can recompile on a lot of systems.
Now I return to this world.
I am understanding that FBP itself is a methodology and is language
independent. I like that. I can do FBP in whatever programming
language I like. There is more than one way to represent an IP and to
represent a PU in code. You do not need any special tools or language
to benefit from using FBP methodology.
I am thinking that it would be nice to have three things:
(1) A FBP environment.
(2) A FBP language.
(3) A FBP kernel.
The Environment would force me to program FBP. So that seems to be the
drawing tool DrawFBP. Whatever I create using the Environment can only
be FBP.
The Language would also force me to program using only FBP. The
Language would not support non-FBP paradigms in which I am accustomed.
Whatever I code using the Language can only be FBP.
By the way, neither the Environment nor the Language would allow me to
create any EPUs. That is because EPUs are PUs created using non-FBP
methodology. And EPUs are necessary because initially there are no
PUs.
The Kernel accelerates my connecting my PUs and passing my IPs.
Without the Kernel, I would have to write code to do what the Kernel
does. Using the Kernel might look like this: At a command line, I type
the name of the FBP Kernel program with the argument being the name of
a FBP network file. The Kernel reads the FBP network file and then
loads and runs my FBP network. The Kernel allows me to mix and match
PUs which may be written by different programmers, each programmer
writing in the programming language of his/her choice. And I don't
care what language each programmer uses. I don't care whether the
programmer is writing spaghetti code, object oriented code, uses
goto's, or whatever. The PUs should be small and simple enough that
what the programmer does doesn't matter much. I only care that the
EPUs work correctly and do not take too long to process IPs. And the
Kernel also threads for me, so I don't have to think about threading
or managing threads (or fibers or whatever).
Seems to me that FBP_CPP or THREADS is the Kernel.
In any case, the Environment and the Language would be like training
wheels because they help me reorient my thinking to FBP. The Kernel
would be useful by providing the functionality that all FBP networks
use. Even so, I do not have to use the Environment, the Language, or
the Kernel. If I want, I can do FBP without any of them.
So, this is where I am in learning FBP. I look to use any feedback I
get to understand FBP better and for encouragement.
Sam Watkins
components, in different domains? I'd like to see a whole lot of FBP example
programs, preferably runnable graphical examples. Maybe we could work on
making more examples for DrawFBP if there are not a lot of examples already.
rlewis wrote:
> object oriented
> structured
> functional
I think the main bonus of FBP compared to conventional sub-routines
and OO programming is that each FBP proc is sort of alive and independent,
with its own processing thread, and they can be connected very flexibly.
Some things I learned, and want to remember and use with FBP,
from other programming styles:
Functional:
- if components are simple and well-defined (not bizarrely eccentric with
side-effects), then the whole system will make more sense, be less buggy
and more 'provable'.
- be consistent... don't treat 0 or 1 as a special case, especially when
handling arguments (or array ports) e.g. sum() = 0, prod() = 1.
UNIX gets this wildly wrong in my opinion, most tools behave differently
if you give them 0 arguments. E.g. plain `cat` should concatenate 0 files,
giving nothing, but in UNIX it copies stdin to stdout! grep behaves in
three different ways for 0, 1 or many arguments. These 'features' can be
good for interactive use, but they make trouble when you try to build
programs out of them.
- lambda is an important concept! in FBP, defining a new composite component
should be nice and clean, like using lambda in a functional language.
Imperative:
- It should be simple to draw shapes and circles on your computer screen,
or play sounds and make music! no harder than it was with BASIC or LOGO.
e.g. MOVE 0, 0; DRAW 100, 100; This can be achieved with modern
languages too, but usually isn't. Old-style GL is not too bad.
In FBP we might have IPs describing shapes, and others describing
vertices, etc. I'm not too sure, but I do want to do graphics and GUIs
with FBP.
Subroutines should have access to context varibles without having to pass
lots of parameters. In OO, methods can access members, they are like
global variables but just within the object.
Structured:
- top-down: divide and conquer! works very well
- bottom-up: build a good toolkit of reusable components, as good as possible
- FBP is a better foundation for structured programming.
- GOTO is very useful. Don't abuse it, don't try to get rid of it!
UNIX:
- Keep it simple! components should do one thing well.
Unfortunately, BSD and GNU have strayed very far from this!
- Processes communicating over pipes, a simple sort of FBP
- UNIX has many useful tools such as comm, grep, sort, awk,
and we can get lots of ideas for useful FBP components from UNIX tools.
I've built a whole lot of small-scale tools too, some of which are useful
or unusual, and could be re-expressed as FBP components.
- The Makefile is a useful approach for data processing also,
it's a bit like FBP but with files instead of queues, each data point is an
infinite queue. Each proc processes all the data before going on to the
next proc although independent procs can run in parallel. If a make job
fails half way, producing wrong data, you can just delete the data that was
wrong, and run it again to continue from that point. There's no need to
run costly earlier steps again. This can speed up development and
debugging compared to conventional progamming or FBP with queues.
So I suggest in a FBP system, there could be a switch for debugging /
development, to enable infinite queues and continuing from a point of
failure. Once all the procs are working, we can switch from files to
queues, lowering latency and increasing parallelism. Or we can have an
option to do it both ways - keep all the intermediate data at each stage,
while feeding it on to the next process as it arrives - a sort of logging
pipe / stream. This could use lots of storage, but it's useful to have a
complete record of each stream at every point. If we save some sort of
serial numbers / timestamps, we could literally rewind and fast-forward
to see where things went wrong, and restart processing from any point
after fixing the problem. Maybe I'm getting carried away here...!
but a time-machine debugger would be incredibly useful I think,
and it would be much easier to implement that for FBP.
Relational:
- Like functional, but components can operate in several directions:
a 'splitter' op that splits lines into words can act as a 'joiner'
op if you run it in reverse. Add and Sub are the same op, just working
in different directions. The reduces the number of basic components,
and composite networks can perform different functions, depending what data
is available and what data is needed.
- A program is declarative, like a big maths equation. We can have rules
to manipulate or simplify it, a bit like a compiler's optimizer, or what
mathematica does with its symbolic algebra.
We can tell the computer what we know, and what we want to be done, and if
we gave it enough information, the computer can figure out exactly how to
do it. (but, we can still specify exactly how to do it, if the damn fool
computer is likely to get it wrong!).
- With FBP, we can think of procs as expressing relationships between
streams, this is like Haskell and the 'lazy functional' languages also,
where you can operate on infinite streams, which are computed only as
needed. I remember Paul mentioned a similar approach in the FBP book.
I want to use a declarative foundation for FBP, it is very good especially
at the low level, but we need streams, IO, and user-interfaces at the
higher level.
Ok, now I'd better stop raving and go and do some work!
Sam
Paul Morrison
time I get discouraged!
Thanks,
P.
Paul Morrison
areas. I also love your idea of keeping a record of the contents of a
stream - that's a very powerful idea. A friend of mine years ago
proposed an "auditing" approach to computing - the data is kept as a
record of all transactions, which can be run backwards or forwards. A
database then becomes just a snapshot of the data at a single point in
time.
BTW Did you know I wrote a tune playing component in JavaFBP - there
is a network that plays 4 parts of Jingle Bells in test/networks/
TestTune.java, and the main component is called SoundMixer.java. It
sounds a bit mushy to my ear - but then I know almost nothing about
PCM encoding, etc.
Regards,
P.
Dan
Sam wrote:> Subroutines should have access to context varibles without
they are like global variables but just within the object.
global variables restricted to that context / object. This is the
problem.
In fact, this is one main problem of OOP. You have a member function
that receives the default parameter "this" that points to a big world
even if the (member) function just operates on a single member
variable, sometimes to none at all.
If you analyze carefully you will realize that this creates a LOT of
false dependencies. This is one of the issues of OOP that drives
programmers to bind not related things together just because it is
simple to pass one default parameter like "this". Why not 2 (two) of
different "this"?
Any component in FBP (including pure functions) can be conceptually
cut out from the network (the reverse of composition. The process is
modeling where the model is the function itself).If you pass as
parameter to the component an entire world it means this component
will depend on that world. In FBP it doesn't make any sense. The IPs
are independent of each other and can be altered / modified /
processed independently. You can pass parameters in this way but just
to READ not to WRITE.
Be aware of the fact that any state variable in FBP (not temporary
variables we use to implement connections) is part of a small or
larger loop. If it is not part of a loop that it means at some point
in time it could be flushed away (consumed) or it just has a "latch"
role. This is a strong idea.
Again, passing an entire object through the default parameter "this"
in OOP creates many problems. This kind of issue should not exist in
FBP BY DESIGN.
flow.It's not a matter of taste using it, it is just a concept in the
imperative world (control flow) not FBP (data flow).
Regards,Dan
John Cowan
> Instead of the mapping using BATs I just described, you can let a
> function (be it a C, C++, C#, or other function) be the PU. The body
> of the function being in a precompiled and included DLL makes the
> function (the PU) a black box. It is a black box because we cannot
> inspect the source code of the PU. Therefore, we are forced to rely on
> a simple description of the function PU's use.
Unfortunately, there are plenty of languages that can't deliver object
code in the form of DLLs.
> The Kernel accelerates my connecting my PUs and passing my IPs.
> The Kernel allows me to mix and match PUs which may be written by
> different programmers, each programmer writing in the programming
> language of his/her choice.
Unfortunately not; you'll be limited to compiled languages that have
implementations capable of delivering shared libraries that can work
without a fixed runtime.
--
John Cowan co...@ccil.org http://ccil.org/~cowan
Promises become binding when there is a meeting of the minds and consideration
is exchanged. So it was at King's Bench in common law England; so it was
under the common law in the American colonies; so it was through more than
two centuries of jurisprudence in this country; and so it is today.
--Specht v. Netscape
John Cowan
> UNIX gets this wildly wrong in my opinion, most tools behave
> differently if you give them 0 arguments. E.g. plain `cat` should
> concatenate 0 files, giving nothing, but in UNIX it copies stdin
> to stdout! grep behaves in three different ways for 0, 1 or many
> arguments. These 'features' can be good for interactive use, but
> they make trouble when you try to build programs out of them.
It's fairly easy to cleverly override this, however, using bash aliases.
> - Processes communicating over pipes, a simple sort of FBP
Pipes are fully general; they are not restricted to pipelines.
> - The Makefile is a useful approach for data processing also, it's
> a bit like FBP but with files instead of queues, each data point is
> an infinite queue. Each proc processes all the data before going
> on to the next proc although independent procs can run in parallel.
> If a make job fails half way, producing wrong data, you can just
> delete the data that was wrong, and run it again to continue from
> that point. There's no need to run costly earlier steps again.
> This can speed up development and debugging compared to conventional
> progamming or FBP with queues.
It would be very nice if DrawFBP had a mode to output such a Makefile,
inventing the temp file names as it goes.
> Relational:
>
> - Like functional, but components can operate in several directions:
> a 'splitter' op that splits lines into words can act as a 'joiner'
> op if you run it in reverse. Add and Sub are the same op, just
> working in different directions. The reduces the number of basic
> components, and composite networks can perform different functions,
> depending what data is available and what data is needed.
This sounds more like Prolog.
--
Cash registers don't really add and subtract; John Cowan
they only grind their gears. co...@ccil.org
But then they don't really grind their gears, either;
they only obey the laws of physics. --Unknown
Paul Morrison
On 13 Nov, 04:56, John Cowan <co...@mercury.ccil.org> wrote:
> It would be very nice if DrawFBP had a mode to output such a Makefile,
> inventing the temp file names as it goes.
>
be happy to add a generator to DrawFBP. From the description, though,
it sounds as if this is something like IBM mainframe JCL - i.e. every
connection is "infinite", and you can only go left-to-right, i.e. no
loop topologies. IMO this is not enough to do full FBP, although you
can certainly do a subset of it. Over to you, John!
Ron, I tried the new format, and didn't find it very friendly - a) it
seems to reorder the posts in a topic, b) when doing a reply it cc'd
the wrong person, and didn't present the post being replied to for
editing. For now, I have reverted to the old format! Does that mean
I won't be able to see your diagrams?!
Ron Lewis
John Cowan
> However, I believe Google is not able to abandon the old format for good
> reason. And the reason has nothing to do with accommodating people who
> prefer the old format.
The usual progression (with Gmail, for example) is "preview the new version",
"switch to the new version", "you have been switched to the new version
(click here to switch back)", and finally "the old version is unavailable."
--
Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus.
Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa!
--Joyce, Ulysses, "Oxen of the Sun" co...@ccil.org
John Cowan
> John, if you send me the makefile format, and some examples, I would
> be happy to add a generator to DrawFBP. From the description, though,
> it sounds as if this is something like IBM mainframe JCL - i.e. every
> connection is "infinite", and you can only go left-to-right, i.e. no
> loop topologies. IMO this is not enough to do full FBP, although you
> can certainly do a subset of it. Over to you, John!
There are three limitations: no loops, all connections are infinite,
and components can have only one output port. However, multiple input
ports are fine. Each connection will have to be assigned a corresponding
filename, which can be derived from the component's name (not its
type, since there may be more than one component of a given type).
Then generate pairs of lines like this:
output-connection-name input-connection-names:
component-type input-connection-names > output-connection-name
Note that the indentation of the second line must be with a \t character;
spaces will not work. The order of line-pairs is not important,
except that the final output component should appear first. The order
of input-connection-names must be determined by the component type: a
simple approach would be to generate them in alphabetical order by port
name (the port name is not meaningful otherwise). The default name for
the generated file should be "Makefile".
So given a simple pipeline like this:
a | b | c
the corresponding Makefile would be:
c-output b-output:
c b-output > c-output
b-output a-output:
b a-output > b-output
a-output:
a a-input-1 > a-output
Typing "make" will then try to generate c-output, note that it depends
on b-output, note that b-output depends on a-output, run the a command,
run the b command, and run the c command. However, if a-input-1 does not
exist, then the process will fail.
That's the general idea, anyway. It may need some tweaking, particularly
when dealing with overall inputs and outputs.
--
In politics, obedience and support John Cowan <co...@ccil.org>
are the same thing. --Hannah Arendt http://www.ccil.org/~cowan
Sam Watkins
what I wrote so I'll post it!
rlewis wrote:
> I think a very positive aspect of FBP is that it doesn't need to be
> expressed in source code at all.
>
> Even so, I feel I need some kind of mapping of FBP diagram to source
> code.
Most languages are parsed from text to give a parse-tree or graph.
Graphs are more expressive than text, and can closely represent meaning.
Text is often more concise, for simple phrases.
Graphs can be rendered into text (to store or communicate them),
e.g. http://en.wikipedia.org/wiki/Trivial_Graph_Format
We can make graph editors, and textual language front ends.
There's no dilemma - we can do it both ways.
Fred might write x = 2y - z, then Jane could edit the
equation as a graph, and Joe might export to 'mathml' or TeX,
then edit it with a tool. File format conversion can be automatic
and transparent.
The underlying graph for that equation looks like this, and closely
represents the meaning. I did not draw any nodes or arcs in ascii!
2
x + * y
z
There's no need for subtract or divide symbols in a relational graph,
and there is no bias toward 'x' as the special 'left hand side'
variable.
We can convert graphs to textual 'back end' languages,
such as Java, C or assembly, or run them directly.
Sam
Dan
There is a problem with the diagram: it does not tell us how the network was built, it is a snapshot of the network at a certain time. It is important how the network is built. For more info please read the post I previously have mentioned.