[mercury-users] Visual Programming

[Richard A. O'Keefe]

Samuel Sean Watkins <108703 at bud.cc.swin.edu.au> wrote

	For many years I've been obsessed with
	developing a programming language / mathematical notation which is
	graphical rather than serial - i.e. not a series of characters, but a
	graph (or network) of symbols and relationships.

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.  Look up Wm Leler's book, and see if you
can find Steele's classic thesis.  If I recall correctly, Steele used
a graphical notation (familiar to anyone who has worked with op-amps)
in part of the thesis.

There is also a moderately large literature on Visual Programming,
some but not all of which is influenced by Data Flow ideas.  When
Gerard Ellis was at RMIT, he pointed out to me that the Conceptual
Graph formalism (a fairly rich graphical notation with roots solidly
planted in logic) can express constraints like this.  Think of goals
as variously shaped nodes and identically named variables as wires:

    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.  There is nothing in this logical formula that says in
what order things happen or which things are solved for what.  Sowa's
Conceptual Graphs demonstrate that _logically_ it is a matter of
indifference whether formulas are presented graphically or in a
Linear Graph Notation (which I didn't use above because I can't
remember it); existing systems like CLP(R) show that constraints
can be solved many ways around.

RMIT once briefly considered switching to a visual programming
language for first-year teaching.

Fished around in archives... There is a "Journal of Visual Languages
and Computing".  You might want to look up PROGRES and GRAS.

	 - however in a graphical notation
	it is easy to do so.  [unfortunately I can't include such a graph in this
	email!]. 
That's why the Conceptual Graphs community use Linear Graph Notation as an
interchange format.
	
	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, it is replaced with
  - an *editing* step (which is rather more work) where the user
    may build or change a graph
  - an *unparsing* step when the user saves the graph to a file
  - *another* parsing step when the user reloads a saved graph from a file
The parsing step may (if you are lucky) be buried in the persistence
features of your implementation language (as in Modula-3, Erlang, Java),
but it is none-the-less a parsing step.  Thing is, parsing is *easy*.

	Anyway, I'm lonely & don't have anyone to talk to about these crazy ideas
	of mine :`( - if anyone's interested, please let me know.  At the moment I
	am working on developing a very simple notation (called ASK) for basic
	concepts such as symbols, bags, sets, substitution, relations and
	logic, but it's pretty unstable and I need some help.  I am also
	developing a notation builder in Java (but possibly I will switch to
	GTK+ once I get the hang of it).
	
	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.
	
	By the way - I don't really know Prolog (I can read, but not write it),
	and I want to learn Mercury the easy way!  I've got Ralph's tutorial,
	which is good - any other suggestions?  I tried reading the reference
	manual, but it was a little bit austere and lacking in examples for my
	liking, I guess it's not meant for beginners.  Did anyone ever read the
	BBC Microcomputer User Guide?  That's the way we should be writing
	manuals!!  I was able to learn BBC BASIC from that when I was in 
	primary school, it must have been well written.  Why don't we try to 
	write a 'Mercury for Primary School Kids' manual?
	
	Thanks for all the interesting mail these couple of years!  (Geez, I feel 
	like a spy now!)  Please let me know if this also is interesting.  Also - 
	is this an appropriate posting, is anyone going to get aggravated like it
	happens on usenet?
	
	Anyone heard about the RISCStation project - I want one of those :o)
	
	
	Sam
	--------------------------------------------------------------------------
	mercury-users mailing list
	post:  mercury-users at cs.mu.oz.au
	administrative address: owner-mercury-users at cs.mu.oz.au
	unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
	subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
	--------------------------------------------------------------------------
	
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------