Comparing Text to Other Structures

We defined the text as a four-way association between units:

<Parent> { <Child> ~ <Role> : <Type> }

with the restrictions: the role unit must be a child of the parent's type unit (or of some ancestor of it) and the type must be consistent with the role's type.

Let us now compare this structure with some software structures that are common today.

Relations

A relation is a two-way association between elements of two sets, (a,b), being a element of A, b element of B, the relationship is a subset of the Cartesian product AxB. Operations are defined between relations: union, intersection, etc.

A text can be seen as a 2nd-order relationship between units:

((p,c),(t,r))

It is not a 4-way relationship, but a double parent-child relationship, between units and their types.

Transformations are defined between text units.

Instead of first defining a relation and then reducing text to it, one can first define text and then reduce a relation to it.

A relation is a trivial case of text.

P { C ~unit :unit}

Being unit the root unit that is defined as a 4-way self-reference:

unit { unit ~unit :unit}

The later approach, that defines text first and derives relations from it, is clearly the better one. A single root definition of text unit suffices, and it is not an abstract concept such as set but a real thing, because text is something that humans can patently experience.

Text is likely to provide a basis for a foundation of mathematics, because it is the only root concept that describes each phenomenon together with the possibility for humans to talk about it. If you begin with ”set“, you must establish a correspondence between a set and the word ”set“; you must explain what sets are, and what the word ”set“ is, and why they match. The same if you begin with another root concept such as ”number“ or ”operation“. Only with ”text“ you don't have this problem, you just need to assume that humans can talk about things. And if you do not admit that humans can talk about things, then you are surely not going to do mathematics at all.

Data Structures

Variables can obviously be represented as text:

=variable1 ~ DATA-TYPE

For languages that support more than one data type, one instantiates DATA-TYPE for each of them.

^ DATA-TYPE
^ NUMBER : DATA-TYPE
^ INTEGER : NUMBER
^ REAL : NUMBER
^ STRING : DATA-TYPE

Many high-level programming languages support user-defined types:

TYPE sometype 
BEGIN
	child1 : type1
	child2 : type2
	child3 : type3
END

Each variable of the defined type is a compound of multiple elements, each of those being a variable of a particular type. The corresponding text would be something as:

^ TYPE : DATA-TYPE {
	^ DATA-ELEMENT : DATA-TYPE
}
= some-type ~TYPE {
	=child1 ~DATA-ELEMENT :type1
	=child2 ~DATA-ELEMENT :type2
	=child3 ~DATA-ELEMENT :type3
}

Some programming languages support abstract data types that have some functionality, called classes or packages.

^ TYPE {
	^ DATA-ELEMENT : DATA-TYPE
	^ CODE-ELEMENT : CODE
}

One can have multiple code elements:

^ CONSTRUCTOR : CODE-ELEMENT
^ DESTRUCTOR : CODE-ELEMENT
^ STATIC-METHOD : CODE-ELEMENT
^ METHOD : CODE-ELEMENT
^ PROPERTY-ACCESSOR : CODE-ELEMENT

Functions

Many programming languages allow defining functions such as:

void dothis(int a, char *b) {
	dothat(a);
	[...]
}

This can be reduced to the following text:

^ CODE-BLOCK {
	^ PARAMETER : DATA-TYPE
	^ STATEMENT 
}
=dothis ~CODE-BLOCK {
	=a ~PARAMETER : INTEGER
	=b ~PARAMETER : CHAR-POINTER
	~STATEMENT : FUNCTION-CALL {
		~FUNCTION ==dothat
		~PARAMETER : INTEGER {
			~VARIABLE a
		}
	}
}

An implicit function such as a lambda expression is simply an embedded function definition instead of a reference ==dothat.

Comparison

Both the relational database model and the programming languages can be reduced to text. For each programming language one defines a set of base text units reflecting the grammar of the language, and then every program can be reduced to it. This is the same that a conventional compiler does, but here the syntax trees are general texts instead of a language and implementation dependent ad hoc structure to which the programmer has no access at all.

The fundamental structural difference between the text and today's languages is that, as we have seen, these languages are restricted to fixed types. You base upon some categories such as CODE-BLOCK and DATA-TYPE, these are established by the language and cannot be extended or replaced by the user. One can design text-oriented languages that allow the programmer to shape this categories. With such a language you can define say a CLASS and then you instantiate some classes, you can construct a special kind of functions that get the code by particular means or whatever. With a text-grounded approach the programmer is not restricted to use some predefined categories, she or he can construct some ones and change or extend them later on.

The second fundamental difference lies in usage. Of course you can use text-oriented languages as if they were conventional languages without changing your mind. But then you didn't get it. The implication of text-orientation is that the programmer specifies software and the compiler implements it. There is no more need for compilers to translate a CODE-BLOCK always as a particular sequence of assembly language instructions that put references to the parameters into the stack and transfer control to a particular memory address. There is no more need for compilers to translate a data type inflexibly as a particular sequence of bytes for storage purposes. Compilers are not restricted to linear translation of sentences into code any more.