Update editrconfig and readme

.editorconfig

@@ -1,7 +1,7 @@
 root = true
 
 [*.md]
-indent_style = tab
+indent_style = space
 indent_size  = 4
 
 [*.c]

Readme.md

@@ -6,8 +6,12 @@ This library is intended for small-to midsize projects.
 
 ### TOC
 
-* [Notes](#Notes)
+* [Notes](#notes)
-* [Building](#Notes)
+* [Usage](#usage)
+* [Building](#notes)
+* [Outline](#outline)
+* [Why](#why)
+* [TODO](#todo)
 
 ## Notes
 
@@ -49,8 +53,8 @@ u32 gen_main()
 This is ofc entirely optional and the metaprogram can be quite separated from the runtime in file organization.
 
 The design a constructive builder of a sort of AST for the code to generate.
+The user is given `Code` typed objects that are used to build up the AST. 
 
-In the current version of the library, constructions are defined with thier paramters in one go.  
 Example:
 ```cpp
 // Get a Code AST from the CodePool.
@@ -66,12 +70,6 @@ Code header = make_struct( "Header" );
 }
 ```
 
-
-
-We first define a Code variable called header. We then open a stack frame for header's components.  
-Header will be a struct so we need to define its body, in this case struct acts a pure POD with only variable member symbols.  
-The components are defined first, then the struct body is constructed. Finally the body is provided the def_struct function.
-
 This will generate the following C code:
 ```cpp
 struct ArrayHeader
@@ -86,11 +84,13 @@ struct ArrayHeader
 ## Gen's DSL
 
 If you don't mind a low amount of macros (29 lines), a DSL may be optionally defined with:
+
 ```cpp
 GEN_DEFINE_DSL
 ```
 
 Using the previous example to show usage:
+
 ```cpp
 make( struct, ArrayHeader )
 {
@@ -104,6 +104,7 @@ make( struct, ArrayHeader )
 
 The `__` represents the `UnusedCode` value constant, of unneeded varaibles.
 The DSL purposefully has no nested macros, with the follwing exceptions:
+
 * `__VA_ARGS__` for parameter expnasion 
 * `VA_NARGS( __VA_ARGS__ )` for determing number of paramters
 * `txt(Value_)` and `txt_with_length(Value_)` to serialize a value type identifier.
@@ -122,26 +123,56 @@ If in your use case, decide to have exclusive separation or partial separation o
 
 ## Outline
 
-### *WHAT IS NOT PROVIDED* :
+### *WHAT IS NOT PROVIDED*
+
 * Macro or template generation      : This library is to avoid those, 
 adding support for them adds unnecessary complexity. If you desire define them outside the gen_time scopes. 
 * Expression validation             : Execution expressions are defined using the untyped string API. There is no parse API for validating expression (possibly will add in the future)
 * Complete file parser DSL          : This isn't like the unreal header tool. Code injection to file or based off a file contents is not supported by the api. However nothing is stopping you using the library for that purpose.
 * Modern c++ (STL library) features
 
+As mentioned in [Usage](#Usage), the user is provided Code objects by calling the interface procedures to generate them or find existing matches.
 
-### There are four different of construction of Code ast's the library provides:
+The AST is managed by the library and provided the user via its interface prodedures.
 
-* Upfront construction
+Notes:
-* Incremental construction
+
-* Parse construction
+* The allocator definitions used are exposed to the user incase they want to dictate memory usage*
+* ASTs are wrapped for the user in a Code struct which essentially a warpper for a AST* type.  
+* Both AST and Code have member symbols but their data layout is enforced to be POD types.
+
+Data layout of AST struct:
+
+```cpp
+CodeT             Type;    
+bool              Readonly;
+AST*              Parent;  
+string            Name;    
+string            Comment; 
+union {                    
+    array(AST*)   Entries;
+    string        Content;
+};
+```
+
+*`CodeT` is a typedef for `ECode::Type` which is the type of the enum.*
+
+ASTs can be set to readonly by calling Code's lock() member function.
+Adding comments is always available even if the AST is set to readonly.  
+
+### There are four sets of interfaces for Code AST generation the library provides
+
+* Upfront
+* Incremental
+* Parsing
 * Untyped
 
-### Upfront Construction:
+### Upfront Construction
+
 All component ASTs must be previously constructed, and provided on creation of the code AST.
 The construction will fail and return InvalidCode otherwise.
 
-API:
+Interface :
 
 * def_forward_decl
 * def_class
@@ -162,7 +193,8 @@ API:
 * def_using
 * def_using_namespace
 
-### Incremental construction:
+### Incremental construction
+
 A Code ast is provided but only completed upfront if all components are provided.
 Components are then added using the AST API for adding ASTs:
 
@@ -170,7 +202,9 @@ Components are then added using the AST API for adding ASTs:
 * code.add_entry( AST* )   // Adds AST entry without validation.
 * code.add_content( AST* ) // Adds AST string content without validation.
 
-API:
+Code ASTs may be explictly validated at anytime using Code's check() member function.
+
+Interface :
 
 * make_forward_decl
 * make_class
@@ -186,10 +220,11 @@ API:
 * make_using
 * make_using_namespace
 
-### Parse construction:
+### Parse construction
+
 A string provided to the API is parsed for the intended language construct.
 
-API:
+Interface :
 
 * parse_forward_decl
 * parse_class
@@ -208,10 +243,11 @@ API:
 The parse API treats any execution scope definitions with no validation and are turned into untyped Code ASTs.
 This includes the assignmetn of variables; due to the library not yet supporting c/c++ expression parsing.
 
-Untyped constructions:
+### Untyped constructions
+
 Code ASTs are constructed using unvalidated strings.
 
-API:
+Interface :
 
 * untyped_str
 * untyped_fmt