KAI Programming Language
========================


Overview
--------

The language is designed to be efficient yet safe by design. This means that it should
be impossible to create unsafe code. But this shouldn't require sacrificing speed.

Programmers know how to write efficient code in languages like C, but then it can be
easy to make a mistake and for the code to be unsafe in unforeseen circumstances.

With C/C++ and similar languages, the burden to be satisfied that the code is infact
safe is placed on the programmer, while a programmer will use logic and reason to
determine this, this is a task which can be automated with tools like static analysers.
But neither are fundamental to the language, and the language doesn't provide any aide
to these automated tools.

Other stategies to achieve safety are to do checks at run-time, but this has an overhead
associated with it. For example, array access using bounds checking. In a C program,
when looping over an array, a programmer can ensure that for the iterations that it will
only iterate on valid array indexes, then each access doesn't need bounds checking,
whereas a run-time check would be a penalty for every access that is not needed. A better
designed language and libraries would iterators which can achieve the same results as
what a C program achieves, but provably correct at compile-time, without requiring
static anaysis or run-time checks.

To work towards creating this language, a number of steps and tools are required to
boot strap this.

- A front-end parser is needed for reading the code and outputting an IR (intermediate
representation) which captures the AST (abstract syntax tree).
- A VM for interpretting and running the IR
- A JIT/back-end code generator for converting the IR in to target specific machine code


Usage
-----

  Front-end parser:

    ./build/translator INPUT.kai

    Currently it can in memory construct an AST of the program and can spit out
    VM asm of expressions in the code. But it doesn't create a full VM asm listing
    of an entire program.

  Assembler:

    ./build/asm INPUT.asm OUTPUT.bin

    Can convert textual VM instructions in to a binary VM program that can be executed
    by the VM.

    Currently the assembler is attempting to create a 'fat' binary which includes a
    .text section and .text_x86 section which are a stream of VM instructions and
    native machine code respectively.

  VM interpreter:

    ./build/vm INPUT.bin

    Can execute the program via the VM. (Currently doesn't use the native machine
    code section of the binary).


Future Work
-----------

Native code generation is only for x64 at the moment, but could add other
targets. It should however be platform agnostic, so only need to compile once
for all OSs which are x64.

Probably the VM could create the native section in the binary JIT, eg at time
of first execution for the specific machine. Perhaps could cache it somewhere
outside of the original binary. That might be a system setting.