[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Flowing Clang executive summary
- To: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Flowing Clang executive summary
- From: Jan Theodore Galkowski <jtgalkowski@xxxxxxxxxxxx>
- Date: Sat, 04 May 2002 10:30:44 -0400
- Cc: JanTheodoreGalkowski <codingwizard@xxxxxxxxxxxxx>, zzdev <zzdev@xxxxxxxxxx>
- In-reply-to: <3CD3A89D.6070802@xxxxxx>
- References: <200204232202.SAA13587@xxxxxxxxxxxxxxxxxxxx>
Thanks for the writeup on Flowing Clang. I have
looked it over, but have not digested it well enough
to make intelligent comments today. I need to
get some other things done first.
Thanks very much. I'll get back to you and the zzdev
list on it.
At 05:23 AM Saturday 05/04/2002, B. Fallenstein wrote:
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
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
- put poswards on d.1 the variables to write its return values
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
- create poswards on d.1 cells representing the return
of the function, and name
- poswards on d.xeq, build a rank of function invocations:
the body of this
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
To create a conditional GOTO in the original Flowing Clang, you
- create a cell on a d.xeq rank and put a question mark in
- negwards on d.1, connect a variable containing a truth
(whether or not to
- poswards on d.1, connect an empty cell on some other d.xeq
(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
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
(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
And now for the fun part.
This structure can be nicely viewed in two ways. First, the
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
[*] 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