I am so unhappy.  I have some conviction that if only I could achieve
something with my visual language project, then I might be happy.  I
suspect it's true, because the main thing making me unhappy is that I
am constantly blocking on this problem.  There is a cycle of
dependencies that is breaking my mind.  In order to do create a decent
graphics system, I need some sort of constraint programming to control
the placement of objects, etc.  However that is one of the most
advanced features that GHost will implement, and not part of a
standard programming language such as C!  So, to create the editor, it
seems I need to create a run-time system for GHost.  To create the
run-time system, it seems necessary to have something to edit runnable
code, so that I can build something to run!  GHost is not easy to
represent in a textual format.  So what the hell do I do?!

I think that first, I should design a textual representation for a
GHost program, so that when I have an editor, it is possible to save
the programs I have created!  The language is closer to Lisp and
Prolog than anything else.  I think I will ignore the issue of visual
layout for the moment, and assume that the editor is clever enough to
lay things out automatically.

OK, here goes.  My example program defines a relation between two
lines and their point/s of intersection.  `m4-mode' seems to be good
for this textual syntax!  It's quite nice, much more intelligible than
Prolog.  It would probably be better if we allowed a functional forms
in addition to relational forms, but this does not fit well with the
graphical syntax.


`lines (line 1) and (line 2) cross at point (intersection)' means
	` `point (intersection) is on line (line 1)' and
	  `point (intersection) is on line (line 2)' '

`point (p) is on line (l)'
	means ` `the coordinates of point (p) are (x) and (y)' and
		`line (l) has equation (a) x + (b) y = (c)' and
		`(_1) is the product of (a) and (x)' and
		`(_2) is the product of (b) and (y)' and
		`(c) is the sum of (_1) and (_2)' '


Clearly this is not sufficient to calculate the intersection, given
the equations of two lines.

For example, if we have these facts:


line (l1) has equation `1' x + `1' y = `1'
line (l2) has equation `2' x + `1' y = `0'
lines (l1) and (l2) cross at point (i)


then we can deduce this:


the coordinates of point (i) are (x) and (y)

(_1) is the product of `1' and (x)'
(_2) is the product of `1' and (y)'
`1' is the sum of (_1) and (_2)'

-- x + y = 1


(_1) is the product of `2' and (x)'
(_2) is the product of `1' and (y)'
`0' is the sum of (_1) and (_2)'

-- 2x + y = 0


We need some arithmetic and algebraic stuff to arrive at a concrete
solution.

the coordinates of point (i) are (x) and (y)
(x) is `-1'
(y) is `2'


These implicit modes are generated when the relation is defined, or,
if the computer fails, the user is queried about them.



Need to distinguish three types of expression - literals (including
statements), variable values and function applications.  Literals are
in `quotes', variables in (parentheses), function applications in
<arrows>.  - subject to revision!


so we can say:

(A) is <<`10' times `20'> plus `5'>

This is a proposition or statement, making use of two functional
forms.  Using only relational forms, it would be rendered:

(A) is (_1) plus `5'
(_1) is `10' times `20'


We also have a set constructor functional form {}, e.g.:

{`1' `2' `3'} maps to (S) under `() plus `1''


and a list constructor functional form [], e.g.:

(L) is [`the' `quick' `brown' `fox']
(L) is <join [(M) (N)]>
(M) ends with `quick'

=>

(M) is [`the' `quick']
(N) is [`brown' `fox']


It might be possible to get the language parser to interpolate missing
punctuation when it is not ambiguous - that would be nice.  Also, to
remove punctuation when displaying to user.  Perhaps we could
rationalise this a bit, and eliminate some punctuation, or use
different fonts or something?


If typing [`a' `b' `c'] is too laborious, we could use <split `a b c'>



Functional forms are just relations on the side, not real functions,
so we can say:


<`6' plus <+- square root (a)>> is <factor of `12'>

=>

(a) is [`0' `4' `9' `16' `25' or `36']


We may need a `macro language' for describing forms, so that we can
neatly cater for convenient forms, e.g.

`... _1 or _2' is `[_1 _2 ...]'




Now I will write a simple recursive parser in cpp for this textual
language, and build a syntax tree out of it.


No - the language does not make sense yet!  Do we need to distinguish
between literals and relational forms?  Can we view a literal as a
relation with no arguments?  That's more like a `type'.

We parse the contents of `' exactly as a normal expression, you can't
have []{}()`' in a symbol name.

The syntax parses to give a graph, not a tree.  This is because symbol
names are joined automatically.