Zilch v1

[Mesabloo]

This is the story of the first version, currently being developed in the basics-dev branch.

Initially, I wanted to do every in small batches (see #7, #9, #15, #16, #17, #18, #19).
Things ended up another way.

Currently, in the development branch, there is an implementation for the following features:

• QTT
• Modules (with a very limited record-like type)
• Basic integers (with widht-varying types) and booleans
• Some control structures such as if-then-else
• Dependent tuples (additive and multiplicative) alongside their eliminators
• First-order functions and types
• Forward declarations, mutual definitions and let/rec bindings
• Term inference and implicit parameters

This has grown way more than it should have been.
However, type inference rules are for the most part already included in the source code. This means that we should be able to simply "copy/paste" them within the specification document.

The current implementation comprises:

• A fully fledged lexer/parser/desugarer combo with early module resolution
• A NbE (Normalisation by Evaluation) typechecker/elaborator with module support

Some steps/features are still missing as of today:

• Metavariables are put in the global scope. We will want to inline them at their (unique) callsites
• Terms may not be monomorphic
• Closures lie everywhere and must be converted
• N⋆ compilation
• Missing enumerations, records (syntactic) and pattern matching with automatic instance record resolution
  See Type classes and named implementations #9
• A foreign function interface (should be similar in treatment within the typechecker to val)
  See FFI targetting C #19
• References and pointers (with region inference) with an unsafe emphasis
• Characters and strings with templating (will see later how to desugar those)
• Algebraic effects as a way to "enclose" impure operations
  See Add algebraic effects to Zilch #7
• Some builtin operations (such as addition of integers, boolean negation, etc.)

There is still a lot of work to do before a minimal viable product for this compiler (moreso if we take in account the issues for N⋆ too, such as zilch-lang/nstar#62). I do not have an ETA for this, and I don't think that one should be such a great thing. I'd rather not put deadlines onto a personal project