A revolutionary OS/Programming Idea

[Lynn H. Maxson]

John Newman writes:
"...From what I gather from these ideas, each and every
object, every construct down to the somewhat lowest
level of the most basic procedures, should have its
own signature--something like a hash value. ..."

Firstly, if you pursue your quest further on the tunes mailing 
list, you had best become LISP friendly.  Almost no respect 
exists here for C++.  More likely you should pay some 
attention to Scheme and Maude, LISP derivatives.

Secondly, I don't suggest using a hash value, but a naming 
convention using two parts, one a content-based value on the 
first X characters in the statement (say 16) and the other a 
32-bit index value appended to the first part.  The difficult 
task of maintaining names must account for synonyms (same 
referent, different names) and homonyms (different referents, 
same name).  This particular naming convention deals with 
resolving homonyms with a side-effect of providing builtin 
version control for every name.

The data repository only stores two forms of source, data 
element declarations (primitive referents) and source 
statements (references).  These represent the "raw material" 
from which we construct all higher level assemblies.  These 
higher level assemblies, data and statement aggegrates, exist 
only as ordered lists of names of "raw material" and  
assemblies.  This processes everything as part of a pure BOM 
(Bill Of Material) manufacturing system, allowing for every 
name to answer two questions: "What is this a part of?" and 
"What are the parts of this?"

If you implement this within a relational database, the 
software tool can use SQL to automatically maintain the two 
source forms, data elements and statement, as well as all 
assemblies (ordered list of names) thereof.  If you extend this 
further to include source text as well as source code, you 
now have an automated basis for "literate programming", of 
associating formal with informal descriptions.

Thirdly, we probably mean different things when we say "file 
system".  When I look at your representations I think "vectors" 
as a contiguous space representation of a set of values.  I 
imagine the LISP people think lists as a logically contiguous 
but possibly physically discontiguous set of values.

Fourthly, syntax results in a body of rules for the 
decomposition of strings of values.  That says you have rules 
for what constitutes a "string" and rules for discriminating the 
values within the string.  We skip over the syntax we have for 
the rules themselves, not recognizing that these in turn must 
appear as strings with values themselves.

The question ultimately comes down to whether or not there 
exists one syntax which we can not only use to define any 
other but also itself.  Historically we have used a two 
language approach, the programming language and the BNF 
(Backus-Naur Form), translating the latter in terms of the 
former.  A "true" specification (and thus programming) 
language would be self-reflexive, thus self-defining and 
self-extensible.