[mercury-users] Visual Programming (again)

[Samuel Sean Watkins]

Here is a response to your replies, and the pretty picture that was 
missing first time (because I hadn't draw it)!

** 

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

**

| > 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 (or 'patterns') 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.

The asymmetry of your two 'expressions' 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 (see the attachment), then most
of this algebraic reexpression is rendered unnecessary, 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 most
modes of the relation directly, without need for reexpression.  Only for
three of twenty modes is it necessary to perform pattern substitution on the 
graph so that it may be evaluated.

**

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

The key is how you *read* the graph, which may be in any mode.

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
Prolog) because it is readable.  However, it is difficult to
see the meaning of your code 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
patterns (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 code 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, the system could suggest optimisations for 
your graph while you are writing it, whereas normally optimisation is 
performed in the compile phase, with no interaction.

**

| On 01-Nov-1999, Samuel Sean Watkins <108703 at 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, and I 
hacked this together in powerpoint (ugh!) 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.  I don't know whether Mercurians consider it
offensive to send large half-off-topic messages to the mailing list - if 
so, I won't do it again.

Sam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ask.png
Type: application/octet-stream
Size: 24506 bytes
Desc: kinematics (png)
URL: <http://lists.mercurylang.org/archives/users/attachments/19991104/9f47a6e3/attachment.obj>