Which is more fundamental, the Function or Relation?  What about sets?  Categories?  Petri-Nets?  Machines?

(aside - I thought of a good way to do the named-columns-dbtools without having to pipe the data through a cat-like process - read the header, output the header, and -exec- whatever program to process the data.  Great!)

My main difficulty with relations / declaration is where to stop.  If I say:

	y = 2*x + 1 or y = 2*x - 1

Then we have a series of levels of declaration:

level 1:
	parameters: x y
	temporaries: t
	constants: 1 2
	relations: * t 2 x	(a)
		   + y t 1	(b)
		   + t y 1	(c)
level 2:
	parameters: a b c R
	temporaries: t u
	relations: and t a b	(d)
		   and u a c	(e)
		   or R t u	(f)

level 3:
	parameters: d e f
	constants: true
	relations: and true d e f	(g)

level 4:
	parameters: g
	constants: true
	declaration: is true g

One thing to bear in mind is that not every statement is either true or false, this is true for self-referential or general (implicitly self referential) statements.  "This statemnet is false" is the simplest of these paradoxical statements.  The barber who shaves everyone who shaves not himself, the set of all sets that do not contain themselves, these are similar.  It may be that not every statement actually defines a valid relation.

Care is necessary with recursive definitions, certainly.  For example, this definition of the natural numbers:

a is in N  <=>
	a is 0  xor
	b is in N and a = b + 1

is all very well as a construction, but other sets (for example the set of natural numbers unioned with the set {x:x+0.5 is an integer} ) also satisfy this relation.

How to properly define the natural numbers recursively?  With a sequence.


and
	first SN 1
	implies
		next SN a b
		succ a b

A sequence is a set of places.  Each place has a "next place", and all but the first place have a "previous place".  Each place has an element.  ???  What was the categorical definition again?

I guess "conceptual graph notation" is already pretty much what I have been trying to create.  What about its quantifiers, and so forth?  It gets too complex.

Okay - next thought in the progression.  A relation is not JUST a set of bindings, it also incorporates some functionality?  query?  hmmm.

What don't I like about normal math notation?
	- not graphical
	- not canonical ( [x = 2y]  =  [y = x/2] )
		- equals sign
		- duplication of operators + - * /
	- quantifiers 'for all' 'exists' are not neat to my mind
	- duplication of notation between sets and statements, although statements / relations are essentially sets
	- emphasis on place value
		- commutative law
	- emphasis on binary relations over others

What don't I like about normal programming?
	- overspecification
		- control flow
		- data structures
		- implementation details
	- lack of generality
	- modules are not usually fully independent
		- ideally each needs its own thread
		- representation-bound

How does declarative / relational programming compare to constructive / machine-building programming, and to functional progamming?
	- declarative programming does not specify what will happen, it just defines relations from other relations.
	- constructive is less general - more functional.  It's not usually practical to have a multi-mode machine. ?
	- functional. like relational, cannot deal with events, it is purely for constructing functions from other functions
	- constructive is more dynamic, has richer modes, than functional (e.g. gates)

..events.. ..sense/motor.. ..stimulus..

What about "abstract machines" - that reminds me of something I have read!  Could we have a system of machines with also "abstract machines" (relations, functions) which must be realised to concrete machines to make an executable program?  YES!!!  Remember Dijkstra's language?  Indeterminacy?  Also abstract objects, which need to be realised to specific structures for execution.  What's the theory called, reduction, refinement?  Yes, refinement calculus.  A valuable idea.  Least precondition, greatest postcondition...?

How to create a function from a relation?  Specify its mode of operation, and precise data types.

Not all machines are functions.

How to deal with end-of-stream?  Machines can die when no inputs left?  This sounds good.  Like unix sig-pipe, but the other way, and voluntary.  Disconnection.

Enough for tonight!

Another idea - to model devices and event-streams as static / eternal objects, so can use declarative / relations to describe dynamic programs.  Use precise times?  Just order?  Seems complex.  But this is really the only way to attack it with mathematical rigor.

Enough.  SLEEP!