Brisk V3

[spotandjake]

Brisk v3 is going to be the next revision of the compiler whenever I get around with it, since writing v2 I have thought a lot more about what makes a good programming language and my goals have completely changed.

I want to write v3 in grain, it is one of my favourite programming languages to write and the functional structure will help to prevent bugs, there are however some downsides to this. Grain is still a relatively new language that is still working on gaining popularity as such there is limited support in terms of libraries which means we will likely need to write a parsing library by hand, I have already written a library for interacting with wasm but this is going to need some changes to support wasmGC and component model.

The wasm, since v2 wasm has come very far and now supports some base level things that allow for compilation to be simplifed a lot, wasm GC will be used for memory collection which means we do not need a malloc implementation, I also want to look into component model for modules which means we would be able to use any linker this also would allow us to link with any language, I do not think the current version of component model supports wasm GC though so we may need to make a decision.

Linking, the current idea would be to use component model to produce indiviual components, the goal being that we can link modules between any language with minimal work and or interop, this needs some massive investigation if this fails or turns out inpractical the backup idea is to either use the brisk linker from v1 (But majorely improved), or develop a new linking standard that is more open.

Goals of v3 compared to v2 from a language perspective, the syntax of brisk is going to change a little, the language will be completely functional with a focus on ease of use and type classes, the ideas here are to greatly simplify the way things work while providing a user friendly experience. This means that all polymorphism and generics are going to go for now. The language will be centered around data types, and should be expandable the more of the language I can write in itself the better. Type classes do raise some concerns though such as where does the implementation of stuff come from and how to trace it with out an lsp some thinking still needs to be done here.

Since we are moving to grain some things are going to change a few notable things that grain makes possible are ADT's, pattern matching and recurrsive functions because of tail calls. This means that the compiler can be written in a performant and data first manner while also greatly simplifying compiler complexity, the compiler will still be multipass as it greatly reduces the complexity of adding new features and allows for some furthur insight into optimization options. The current phases of the compiler I can forsee are parsing, analysis, typechecking, ast_simplification, late optimization, ast_lowering, output, with the descirptions below:

• Parsing - This will likely be a recurssive descent parser working directly on the input token stream instead of having a lexer it will just be a parser and lexer in one.
• analysis - This process runs over the source code and makes notes on things, it might attach comments to their sources, mark variables, determine if functions have side effects and the likes.
• Typechecking - This is going to be the heart of v3, whereas before brisk got away with a very simple typechecker now we are going to need to make things quite a bit more complex given we will have typeclasses.
• ast_simplification - I still need to find a better name for this pass but the idea is now that we have the typechecking info all sorted out we can now convert calls like "x".toString() into calls such as String.toString(str), and the likes which makes simplifies the work the idea is we will output from here into a much more simplified and streamlined ast that is easier to work on, and needs less type mapping.
• Optimization - Now that we have done all the complex stuff we want to optimize things like dead code analysis, duplicate_expression optimization and the likes will be done here.
• ast_lowering - This needs a better name too but the idea here is that we lower from a high level interpretation down to somethign a little closer to the wasm interpretation which should help with the wasm step.
• output - This is the step that actually generates our code.

The current compiler is very monolothic with all the compilation happening in one place, I want to split this version up a lot more with an emphasis on isolated modules, The goal is to be able to compile all the modules seperatly without any context as to what the other modules look like and then be able to typecheck the entire program after and link them, alternatively we might have two stages before compilation a stage that does a very quick half parse of the file extracts the dependencies and then recursively does the thing until we have a list of dependencies, we can then run typechecking over all the depencies in a tree like fashion and do a final compilation step afterwards.