[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: [zzdev] Flowing Clang executive summary

Benja,

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.

  --Jan


At 05:23 AM Saturday 05/04/2002, B. Fallenstein wrote:

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.