Here is a response to your replies!

**

| It also has a lot of practical problems:
| how do you neatly lay out graphical programs?  How do you debug them

There are evolutionary algorithms which do a very nice job of automatic graph layout -
for example, Dr. Dobbs' journal #302, Aug'99 ran an article on this, in an issue
entitled 'Visual Programming'.  I expect that a user would want manual and
automatic graph layout features.  I admit it is difficult to work with graphs on paper -
a whiteboard is somewhat better.

Debugging!  Well, how does bi-directional algorithm animation sound to you?
You can watch your program running, examine your data structures as they
are being determined, modify your 'code' during execution / simulation ... :)

**

| In the second place, the compiler needs to know that * and / are duals,
| which is harder to express.  Work is going on to help you express properties
| like this to the compiler:
| 
| :- promise all [A,B,C] (A = B/C <=> B = A * C).

In a graphical algebra, there is only the one symbol for * and /, so the compiler
needs no such 'promise'.  The procedural effect depends on the mode of
utilisation.  If you have a language which supports a variable number of
parameters, you can also use * to mean 1 (give it no arguments) and + to 
mean 0!  I don't know if that's desirable, but it's certainly interesting.  I
have experimented with a notation where expressing 1 + z - 7 = a + b + 2 requires
only a single (additive) operator!

**

| > In my opinion, the 'promises' of commutativity (axioms, I
| > guess) which were
| > mentioned recently are really just an artifact of an
| > inexpressive notation
| > - in fact, addition and multiplication each operate on a bag
| > of numbers,
| > and bags aren't ordered, so commutativity is implicit.
| 
| Au contraire!  Place-value notation is very important.  For example, it's
| important to get the order right when concatenating strings; of course, you
| don't really care when you're adding floats or ints.  If you don't have
| place-value, you're really stuck.

Of course place value (or order) is important in general, but not for the multiply or
addition operators.  Sequence concatenation is an relation between a
sequence of sequences (the arguments) and another sequence (the concatenation), and
could also be used to split strings (or even to perform simple lexical analysis) in
another mode.

**

| Complex relationships would still end up looking like a complete mess of
| links, however. The way to minimise this mess would be the analogue of
| "style" in textual programming, I guess.

No, it would be the analogue of "structure" in textual programming.  I envisage
a system where new relations may be defined (and treated as values if need be),
so you get (at least) the power of LISP's lambda calculus for structuring your programs.
You should also be able to make multiple images of labelled nodes, if necessary
to improve readability.

**

| There's a moderately large literature on Constraint Programming Languages,
| which can handle things like your
| (1)     disp  = initial*time + accel*time*time/2,
| (2)     final = initial + accel*time
| example.  I'm a little puzzled as to what the "5 equations" could be;
| there are five parameters, and you can obviously vary the initial
| velocity, the constant acceleration, and the elapsed time freely,
| so two equations seems like the right number.  There are indeed 20
| directional algorithms that can be derived from this, because 5-choose-2
| is 20.  The claim that "in a serial language, such as normal algebra,
| English or Mercury, it is impossible to represent such a complex
| relationship elegantly and symmetrically" is completely baffling,
| I just *did* express the relationships between these five parameters
| elegantly and symmetrically.

Sure, any two of the five equations is enough to determine the complete relation.
There are five different single equations which each relate four of the five
variables.  The 20 directional algorithms are obtained by choosing a variable to exclude,
and choosing a variable to find, the other three being given (hence 5-choose-2).

The asymmetry of your two equations is the following:

If I am given 'inital', 'time' and 'accel', it is easy to compute 'disp' and 'final'
by simple substitution of values into your equations.

If, on the other hand, I have been given values for *any other* triplet of the variables,
(e.g. final = -1, accel = -9.8 and disp = 4) I will need to considerably rearrange your equations
(which may involve solving a quadratic) in order to find values for the other two variables.

If the relation is expressed graphically, then no such effort is necessary, as
there are no '=' signs (or else each link is an '=' or 'unify' sign), and no variable is
favoured above the others.  In addition, a computer may simulate any mode of the
relation directly, without need for reexpression.  This is the symmetry I was
referring to.  I have attached an example graph, hopefully its small enough
to be forgiven!

**

|     times(Accel, Time, A_T),
|     plus(Initial, A_T, Final),
|     times(A_T, Time, A_T2),
|     times(A_T2, 0.5, Half_A_T2),
|     times(Initial, Time, I_T),
|     plus(I_T, Half_A_T2, Disp)
| 
| We may write the characters one by one, but we draw graphs element by
| element too.

I guess it is necessary to have a textual equivalent for dumping the graph to
a disk - but Java's serialisation would also acheive this, as you suggested.  I
tend to prefer textual serialisation (such as XML or your conjunction above)
because it is readable.  However, it is difficult to see the meaning of your
conjunction at a glance.  A graph is transparent to meaning, if a person is
familiar with the notation!

**

|         A graphical notation is an excellent medium between computer and user,
|         because it is very easy for the user to manipulate, and it eliminates
| the
|         parse step of compilation.

| There are some misconceptions here.
| Graphical notations make it easy to manipulate *SMALL* graphs.
| The parse step is *not* eliminated

A program might be a hyper-textual (well, not 'textual'!) document with relations
and symbols defined using small graphs.  Declaring relational equivalence and containment
(treating a relation as a set of bindings, and declaring relationships between relations
using the normal set relations like =, subset, union, etc.) is an interesting possibility;
you can use set relations in place of predicate / propositional calculus, e.g. 'subset' is
'implies', 'union' is 'or', etc.

I understand parsing to be the analysis of textual source to build a parse tree, a (type of)
graph in the computer.  If you program graphically, you are assembling the 'parse graph' using
direct manipulation.  For example, you could view the operation of an optimiser upon your graph,
and interact with this operation, because the computer can manipulate a graph as easily as you can.
Optimisations such as 'common-sub-expression elimination' could be naturally performed by the
programmer in a graphical language.

**

| On 01-Nov-1999, Samuel Sean Watkins <108703@bud.cc.swin.edu.au> wrote:
| > [unfortunately I can't include such a graph in this email!].
| 
| This suggests to me that the time for visual programming
| has not yet come ;-)

Okay, I was just being lazy!  The notation is still embryonic, so forgive me if its not very nice.

**

Thanks for your interest!!  Sorry about this monster email, I don't check mine as
often as I should.