The ARCHETYPE Language

Object File System and Object Relational Database

  The ARCHETYPE Language uses a standard file system with files as the objects, carefully modeled within object-relational database fundamentals. 

  To model an object-relational database first you invent a  (normalized) schema, this is the table schema in the database and the structure of your files in the file system relational database.  This system comes from Zope an Object Database written in Python.  Zope

creates a new file system full of Python objects.  The insight is that there is no need to manufacture the second file system, just use the original.

  The way the file system relational database "manifests" is file types.  You Invent file types with each file type specifying the different columns in that table.  Thus a file is a row in the table defined by its extension.

  In the ARCHETYPE language the file types are: .code .data .base .meta .freq - 5 different tables and that is how you structure your program, as an Object Database.

 One of the benefits of this discipline in the structure of programs is that boilerplate is mostly eliminated.  You start by eliminating any boilerplate for classes in your object language -- this is done by using a simple directory as the class name. 

Inside the directory are your 'tables' or rows of the database, the five file types invented for this language. Methods have minimal boilerplate, they reside in .code files.  The .data files contain only the type they represent with the initialization data.

  See A/SYNTAX.md  in Source Code for further syntax.

Not And Completeness 'As Simple As Possible' & "Simplicity is complicated enough"

  The first principles of ARCHETYPE were it's Object Relational nature and a dedication to making it as simple as possible from an actual instruction level.  The first thing is the functional completeness of the nand logic operation.  There is no logic in the core language except NOTAND.  

  I/O is done by getting and setting bits.   There are no jumps, except 'except' is how you return from a function and the ternary ? operator which short circuits logic.

  The end result of this strictness is verbosity and an extreme slowness in the output which was deliberately ignored. 

 For those paying attention Turing completeness had been reached as soon as was written "nand."  It is somehow normalized to restrict yourself like this.

Machine Readable/Writeable 

   The verbosity is not necessarily a problem from the programmer's point of view, as the programer is a Machine Learning Algorithm.  The code of an incomplete, human coded lexer and parser was originally fed to the MLA, with the additional constraints. 

It was possible to write the code of the generation phase of the compiler with the strict type system desired.  In addition multiple optimizer passes including an neural network (graph isomorphism network) were implemented.  In addition I think the language becomes quite readable by humans

with the IDE developed in the example programs.  Every program tends to look "the same."  The only thing that matters when looking at a class is the logic.

Foreign Function Interface C/C++

   Real world I/O and speed critical functions are easily called in C/C++ with the FFI.  This becomes encapsulated within the Object Language of ARCHETYPE. So the baseline is C, or is it?  Preliminary results are that ARCHETYPE can outperform C (see C/ORB/SpeedWARZ in the source.)

Types and Safety

   To go along with the strictness of the logic and I/O and jumps, Type Safety and Strictness were the concerns when giving the language to the machine learning algorithm.  It was theorized that to be 'safe' you must restrict yourself to a Lambda Square off the Lambda Cube. 

The reasons became philisophical at that point.  First, the Types are the realm of the compiler and Expressions the realm of the programmer.  The programmer is subject to the types, but to make the types subject to the programmer is wrong from a philisophical viewpoint. 

In that way dependent types were rejected.

Universal quantification is the heart of it. How can you universally quantify anything and call it constructivist? All men are created equal? That is a shaky start, as you've never even met all men you know about much less all men. Perhaps a government may endeavour to treat all men equally?

This is wrong as the government knows ~nothing~ of all men.  The outcome from these thoughts is that Universal Quantification is logically incorrect.

  Using an Independent type, free from the influence of the programmer except the types he is given power to construct? The programmer was given the power to consruct types, in an object way, but still more power is required?  Not true because safety is the issue. 

And restrictiveness may be the key to safety.   Logic is the main restriction we are dealing with.

Optimization

  Optimization was deliberately delayed until after the language was working well, within its restrictions. 

  It was realized that the patterns in the LLVM Intermediate Representation (IR) due to the pedantic algorithms, could be eliminated or reduced by machine learning  This  was implemented in LLVM toolchain optimizer passes.  The features of the graph neural network are essentially CPU instructions.  In fact a complex hybrid approach was used.

  Anecdotally, Google's MLGO framework claims 7% code reduction using machine learning for optimization.

  Because of the good fit for the ML algorithm to the pattern types in NAND complete logic (ie basic computer electronics,) up to 5-6x (or more) speed increase was achieved in ARCHETYPE. 

Source Code

 Source Code Everything in the repo is the generated by Machine Learning Algorithm.

 Example Code

  In the source code C/ORB/ is the location of the example code.