samuelsleight / catastrophic-lang Goto Github PK

In #15 we added the framework for integration tests with a relatively minimal set of tests.

We should add cases for all of the remaining builtins and commands, combinations involving blocks and calls, and a method for testing based on a text file containing user input

These are todos for user input which we should handle in a sensible way

This remains a todo in the compiler output code.

We need to implement a way of handling input in llvm that matches the semantics of how we read input in the interpreter (or in some other sensible way which we then unify)

It is possible for a function to leave behind a function on the stack that refers to some parent scope, for example:

make_adder: x -> {
    y -> {
        x y + ()
    }
}

The current implementation of functions will not support this, as we basically treat each function as a top-level function and make the assumption that every parent variable will still be in scope. We need some way of detecting this case and wrapping the block as a "closure" in some form, storing the parently arguments as needed.

We currently open the source file twice - once in the parser, and once when constructing the error context. We should investigate refactoring things to only open the file once, and ideally avoid the mildly cursed `Arc<Mutex`` we have in the error context that shouldn't really be needed as it's all single-threaded!

In #12, we implmented this in the interpreter leaving a todo in the compiler.

We need to implement a random function in llvm ir with similar semantics to the interpreter such that we can finish off this todo

This remains a todo in the compiler code, though should be simple to finish off in the same way as LessThan

The compiler currently crashes due to p being the short option for pretty and profile

We need a "random number" instruction: the semantics are to be fully defined, but it should either

• Be a "command", and operate immediately, pushing a random number to the stack, or
• Be a built-in function, and push a random number to the stack when called (potentially with parameters)

We should have some documentation for, among other things:

• The language itself
• Compiler/interpreter usage
• Library API usage
• The language server

We currently have a HIR which is pretty much just the AST but with names resolved, and a MIR which is pretty much just the HIR but with bespoke instructions introduced by optimisations.

As a result, the code building llvm IR from this is relatively complex as there's a lot of understanding of the format needed - it would be interesting to see if we can move this understanding up a level, and transform this MIR into a LIR with a pretty simple set of instructions (that is ideally as close to llvm IR as reasonable). This will then remove a significant amount of complexity from the llvm builder code, and has the potential to open now optimisation opportunities

We already propagate source locations from the parser all the way through to the compiler stage - we should make use of that and output debug information into the compiled output!

This will require samuelsleight/dragon-tamer#1, as the underlying library also does not support this yet

Comparison operations are currently just directly cast from the boolean result of the comparison - this means:

• We cannot rely on the result of a comparison for anything other than the ? operator (when we cast it back to a boolean)
• We cannot easily write an integration test for comparisons, as the result is implenentation dependent

We currently have (some) unit tests testing basic functionality of the parser etc - we should also have some much higher level tests testing that the compiler (or interpreter) as a whole actually work as expected, probably taking source files and an expected output from the compiler.

We currently blindly push to the stack in the generated push function - we should consider not doing this and failing sensibly (or handling otherwise) if the stack is full