🚧Anything and everything might not work and much isn't yet implemented🚧

• Fewer keywords than C. "An idiot admires complexity, a genius admires simplicity" - Terry A Davis
• Infallible type inference unlike Rust which constantly fails to infer type infomation.
• No stack overflow becuase there is no recursion. There is always a better iterative solution.
• No hidden memory allocations unlike Zig which still does fallible stack allocation.
• Formal verification like Ada but simpler.
• No generics or templates becuase it doesn't need hints to figure out the types that work.

Supports aarch64. Doesn't support RISC-V. Won't support x86-64.

Hello, World!

Keywords

1. if: Rust's if without the brackets¹.
2. loop: Rust's loop without the brackets¹.
3. break: Jumps out of the current loop¹.
4. def: Python's def without the :².
5. in: The arguments given to a function³.
6. out: The output given to a function. a := b - c + d after unrolling and type inference is equivalent to

   c + d @ x
   b - x @ y
   a := y @ null

   @ can only be defined on the outermost expression in a line, the outputs of nested expression are used to chain the expressions together.
7. fail: If reachable triggers a failure in formal verification.
8. assume: Mark code which will be passed to formal verification but excluded at run-time. assume x %= 4 tells the verifier { 0 ≤ x < 4 }.
9. valueof: Gets the value of a value.

   a := valueof 1 // a = value_literal = 0
   b := valueof c // b = value_variable = 1

10. unreachable: Marks the end of execution, all following statements are unreachable.
11. macro: Similar to macros in C. Macro evaluation happens before the AST is parsed and simply performs a find and replace on the text contents of source files. Since := is a function, macro is how constants used in the definition of := are defined. Unless writing your own core, you should never need to use this.
12. asm: The prefix for a line with in-line assembly e.g. asm mov x0, 1.
13. section: Defines the valid address space.

    section 100 200 read // read 100 to 200
    section 300 400 write // write 300 to 400
    section 500 600 readwrite // read+write 500 to 600

Notes

1. if, loop and break will be removed as intrinsics and added to the core library as functions when the compiler is re-written in the language. At this point functions will be able to mutate their child AST. This will enable equivalent support to procedural macros found in other languages but better.
2. I'm not commited to using def as the function keyword. I'm considering fn.
3. I'm thinking about splitting in into lhs and rhs as this will make all input patterns differentiable to a function. Currently with in when you have a function my_function calling it with a my_function b or my_function a b appears identical to the function.

Features that might require new keywords

1. Generation of unique errors codes.
2. Defered logging.
3. Non-exhaustive checking. E.g. use gradient descent to search for a minimium to check.
4. Starting new threads during execution. The current assumption is based on bare-metal where the program begins with all hardware threads running.
5. Functions mutating the AST like procedural macros. This would be a massive usability improvement over traditional macros and even procedural macros, in essence it would allow every function to access a pointer to its location in the current AST and then edit it dynamically making all functions more powerful than the most powerful macros in other languages. This is accomplished through the formal verification mechanism which can check that all paths resolve to the same AST.