Flowing Clang executive summary

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Hi Jan--

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.1
    d.xeq ("execu," for "execution")
    d.clone

Today I would likely also use a fourth dimension--
    d.goto

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 
variables[*]).

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].

- Benja

[*] 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.








JanTheodoreGalkowski wrote:
> Hiya Benja,
>
> 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/
> project.
>
> 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
> provide.