[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Flowing Clang executive summary
- To: JanTheodoreGalkowski <codingwizard@xxxxxxxxxxxxx>, zzdev <zzdev@xxxxxxxxxx>
- Subject: Flowing Clang executive summary
- From: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Date: Sat, 04 May 2002 11:23:41 +0200
- References: <200204232202.SAA13587@xxxxxxxxxxxxxxxxxxxx>
Ok, here's an executive summary of Flowing Clang:
It's kind of a cross between an assembler and a dataflow language. More
specifically, it's a somewhat assembler-like language, but with
subroutines and a dataflow visualization.
In Flowing Clang, everything is organized into functions-- there are no
bigger units. Each function has an arbitrary number of arguments and
return values. Organizing functions into related groups is done in other
zz dimensions, completely orthogonally from Flowing Clang.
The dimensions the original design used were--
d.xeq ("execu," for "execution")
Today I would likely also use a fourth dimension--
The body of a function consists of invocations of other functions (or
primitives). To INVOKE a function, you:
- clone the function's maincell (definition)
- put negwards on d.1 its arguments (as variables or literals)
- put poswards on d.1 the variables to write its return values into
A cell becomes a recognized variable by being written some value into,
normally by being on some invocation's return value list. Variables are
cloned on each parameter/return value list they're on. Variable's values
are local to one call to one function (i.e. there are no global
To string invocations together (for sequential execution), you make a
rank on d.xeq. I.e., you string together the clones of functions on
d.xeq, with the arguments connected to them on d.1.
To CREATE A NEW FUNCTION, you:
- create a new cell and put the functions name into it
(this will be the *maincell* of the function);
- create negwards on d.1 cells representing the arguments
of the function, and name them;
- create poswards on d.1 cells representing the return values
of the function, and name them;
- poswards on d.xeq, build a rank of function invocations:
the body of this function.
Note: Being a function's parameter is the only way for a cell to become
a variable other than being on a function invocation's return value
list. I.e., when a function is called, the argument values are written
into variables represented by the cells negwards from the function
definition; thus, those cells become variables.
Now, so far we're missing control flow. *All control flow in Flowing
Clang is handled through GOTOs.* GOTOs in zzstructure aren't harmful as
they are in textual program code, because they're *bidirectional*: When
looking at a GOTO's target, you can see its "COMEFROM" (the GOTO).
To create a conditional GOTO in the original Flowing Clang, you would:
- create a cell on a d.xeq rank and put a question mark in it;
- negwards on d.1, connect a variable containing a truth value
(whether or not to branch)
- poswards on d.1, connect an empty cell on some other d.xeq rank
(the GOTO's target)
Execution will continue at the GOTO's target if the parameter is "true"
and below the question mark if the parameter is "false."
The point of using d.1 was viewability in two dimensions. Today I think
it would probably be better to avoid this overloading, and connect the
GOTO target on a fourth dimension, d.goto. (I would also make the
"conditional goto" special form a cloneable cell and not
a magic string.)
Unconditional branches can be realized by some other special form (in
the original FC implementation, simply an empty cell), only allowable at
the end of a d.xeq rank. They're connected to their targets in the same
manner (d.1 or d.goto).
A function returns when execution falls off the end of a d.xeq rank.
Then, the values of the variables represented by the cells *posward*
from the function definition (on d.1) are read. These are the return
values of the function.
(It is an error for these not to have been assigned values yet, at the
time the values are read. Function invocations' arguments, on the other
hand, are treated as literals if no value is assigned to that cell as a
variable-- if I recall correctly.)
Note that looping ranks on d.xeq are perfectly allowable (as long as the
function definition is not on that, but on another rank). Indeed,
looping d.xeq ranks are the prefered way of realizing loops in a program.
And now for the fun part.
This structure can be nicely viewed in two ways. First, the obvious:
X axis = d.1, Y axis = d.xeq
This is the "imperative" view of the program, used for editing. Here's
the "dataflow" view mentioned above:
X axis = d.1, Y axis = d.clone
This works because *all places where a variable is used are connected as
clones*. Thus, you see where in the function a varaible is set and where
it is read as a vertical rank (row/I view is useful).
As arguments are put negwards and result values poswards from a
function, data appears to 'flow' from the upper left to the lower right
in this visualization (unless the dimensions are flipped).
Of course this is just a nice view; the semantics of Flowing Clang
remain the ones of an imperative, not a dataflow language.
Ok, I hope this helped. If you have questions, please ask.
Obviously this is a very simplish language, intended for experimentation
and for showing conrol flow clearly in the zz fabric. Other clang
designs have been created with different design goals [Thales Clang,
Archimedes Clang, Clasm].
[*] Global variables are not needed-- you can always write into a
hard-coded cell. Local variables *are* needed because if a function
calls itself, we want to have different stack frames.
Well, I've started the implementation
in Smalltalk I wanted to do. The
"flowing clang" reference was
something Ted mentioned in reaction
to some ideas I had on doing
programming in zzstructures, after
reading the "manual" at
xanadu.net/zigzag. I knew you had
done some thinking/work on the
topic. Ted suggested "clang". I
don't know anything about it, but
it always pays to learn as much as
possible from people who have
worked in and thought about subjects
much longer than you have.
I do not want to burden you. I just
thought it was worth learning about.
Good luck on your presentation/
I had hoped to be much farther
along than I am with it, but all of a
sudden I got a high overtime, short-
term software gig from a client after
having had nothing for 2 months.
Yes, I get raised eyebrows with
"orthoplex computing", too.
Thanks for anything you can