Editing Programming Language (section)

=File Structure=
* File signature.
* Version.
 
 [4244 4e49 535f 4352] <- [https://en.wikipedia.org/wiki/List_of_file_signatures File Signature]. "DBIN_SRC"
 [9ff0 84a6 000a] <- These bytes should be ignored.
 [0x00 0x00] <- Binary file format versioning... Is 2 bytes good? Should it be in human readable ASCII? This hopefully shouldn't change. If these are anything higher than 0x00 the parser should check the next number to see if the new version is backwards compatible.

 <strike>[XXXX] <- A 2 byte offset. The parser should advance by this amount. This is to allow for an extra emergency block of information at the to top level. Normally it will be 0x0000.
 [number of bytes specified above] - This will contain any emergency data that is needed. It should not be used for adding any custom user data. A future version parser might need to read information from it (is this needed, probably should just be in a generic 'extra stuff' category?).</strike>

==Types==
* 0x01 - List
 [0x01][u64: number of elements]([element])... - num=Number of elements, followed by elements. TODO: Should lists include the size in bytes? What about the 'type' they contain? Mixed types?
* NoEnum - Version. Binary file version (2 bytes). Not the source code version.
* 0x02 - Name
 [0x02][u8]["UTF8_Name_Goes_Here"] - u8 refers to unsigned 8-bits.

==Root List Enums==
* 0x01 - File Properties List
* 0x0X - Defined symbol names.

===Binary File Properties Types===
* 0x00 - sha3 File hash. This must be zeroed when actually calculating the hash.
 [0x00][64 bytes]
* 0x01 - Minimum binary file format read/write version. If the parser wasn't coded against this version or greater, it should bail out. For the first version if these 2 bytes are anything other than 0x00 you should error with some kind of "Unsupported version" message. If this is missing assume the minimum version is the same as the one in the file header.
 [0x01][version]
* 0x02 - Minimum parser file format read only version. If the parser wasn't coded against this version, it can still read it but it should prevent saving/re-serialisation of the file format as that could result in data loss. It should either error out or confront the user. It's also acceptable to just error out and not bother to implement a read only mode.
 [0x02][version]

==Compiler is a Daemon==
* Watch file system for changes are start to parse/compile with cancellation.
* Continuously compile file in memory while its still being edited if supported.
* Cache all parts of the compile pipeline. No need to re-parse a file that hasn't been edited. No need to recompile a function that hasn't changed.

==Implicit unit testing==
* Quickcheck style unit tests. Results stored to inform you if the results change. Alert you to common corner errors.

==Solve the halting state problem 🤑==
* Obviously not really.
* Look into termination analysis.
* Look into dependant types, etc...
* Best effort. 'Halts', 'Doesn't halt', 'halts when input is X', 'Unknown'...
* Look into subsets of programs **can** be checked.
** When there is no loops/recursion.
** When loops are fixed at compile time.
** When there is an obvious infinite loop `for(;;){}`.
** Self modifying programs.
** A lot is dependant on external inputs.
** Limitable loops.
*** Injectable via a context.
*** A for loop that can't run longer than 10 seconds. "This function will halt, because I will halt it if it doesn't".
*** A loop that can't do more than X iterations (X could be the size of an array, that size would be limited by the size type).
*** Could be a source of bugs though...