One big goal I have with brisk is to move the language into itself. Steps towards this are for instance custom operators and macros they allow a lot of logic to be figured out inside the language and remove bloat from the compiler this has advantages and disadvantages but I like this approach a lot.

Some more things we might want to look into are:

• Macros
• Syntax Sugar
• Representing more as functions and just having the compiler call those functions and then let our optimizer optimize the funciton calls away.

implement malloc and gc in brisk.

Is your feature request related to a problem? Please describe.
Moving things like optimizations and verification, along with type checking to work on the generated code rather than the parse tree should result in faster, better memory efficiency and will allow our compiler to work in a lot more situations along with allowing us to keep keep the same optimization steps while adding more features into the codegen step.

Describe the solution you'd like
Move from optimizing and verifying from the Brisk code to work on the wasm code.

Describe alternatives you've considered
Compile down to a very basic version of brisk that doesn't have heap types and doesn't have closures and functions.

Additional context
Golang works in a similar way where it generates the output code earlier and then performs things like optimization on the generated code which can lead to faster compile times.

add support for wasm stack values that are off the heap this will let us write things like malloc directly in wasm

add instructions from lower level wasm for writing the stdlib

  // Memory
    // Briskload(Pointer: i32, offset: i32) -> i32
    // Briskstore(Pointer: i32, offset: i32, data: i32) -> Void
    // Brisksize() -> i32
    // Briskgrow(pages: i32) -> i32
    // _Malloc(Size: i32) -> i32
  // Math
  // Control Flow

Improve Malloc so it can handle fragmentation.
Create a free Function.
Look into changing how things are stored look into aligning data and using single bits for booleans.

replace nearly with a custom parser.

Write Better documentaition, planning, and maybe a website

Type Check Function Calls.

Write Unit tests for each part of the compiler and brisk langauge.

Describe the bug

//if (1n == 1n) @wasm.i32.add(1n, 1n);
if (1n == 1n) {
  print('Test');
}

The Code Above Creates A Parse Error Even Though it Is Valid.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Rewrite Language According to Language.md

Write an stdlib for print, math, and more.

Add a math library for working with grain numbers

add(Number, Number) -> Number
sub(Number, Number) -> Number
mul(Number, Number) -> Number
div(Number, Number) -> Number

add a runtime mode that only has the wasm stack types, no closures or first-class functions to let us write GC and malloc.

Write a replacement for binaryen so we do not need to rely on external dependencies once ported into brisk

Add Records To The Language.

Things To Add To V2.

• Add Match Statements
• Enums
• GC
• Type Guards
• Heap Types
• Linker
• Optimizer

Write a type checker for brisk.

BootStrap brisk, Rewrite Brisk in itself, This is a massive task as it will require a fully working compiler and standard library and then I will have to ditch any javascript libraries I am using and reimplement everything in brisk. The benefits of this are brisk will be completely standalone, This will encourage a good standard libary and will help with battle testing the compiler in general as it will be a massive project.

write a verifier to verify, all imports exist, and things of this nature

Add support for arbitrary precision numerics,
add support for rational numbers so we have more precision on floats

when you have the code

let loop: Function = (body: Function): Void => {
  body();
  loop(body);
};
loop((): Void => {
  print(1);
});
``` this doesn't work because at the time of making the closure

Port each component of brisk into brisk.

add static module linking to the compiler.

let loop: Function = (body: Function, self: Fuction): Void => {
  body();
  loop(body, self);
};
loop((): Function => {
  print(1);
}, loop);

the code above results in

RuntimeError: memory access out of bounds
    at 0 (<anonymous>:wasm-function[1]:0x5c)
    at 0 (<anonymous>:wasm-function[1]:0x7b)
    at main (<anonymous>:wasm-function[3]:0x243)
Error: abort(RuntimeError: memory access out of bounds). Build with -s ASSERTIONS=1 for more info.
    at process.q (C:\Users\Spota\OneDrive\Documents\GitHub\Brisk\Brisk\node_modules\binaryen\index.js:31:176)
    at process.emit (node:events:394:28)
    at emit (node:internal/process/promises:136:22)
    at processPromiseRejections (node:internal/process/promises:242:25)
    at processTicksAndRejections (node:internal/process/task_queues:97:32)

replace commander with a custom solution to reduce lib count

The current type checker while it works somewhat, it was made on the basis of what I needed at the time with little research into actual type checkers.

We want to rewrite it completly from scratch to support Type Intersection, Polymorphism and Proper Type Compatibility Checks.

What we need to determine:

• Does Brisk use structural equality or Nominal typing or A Mix of both this is very important currently brisk Mainly uses Nominal typechecking with a hint of Structural typing I really like this approach but I feel like we need to write out and prove the rules before they can be trusted.
• Helper functions, A lot of the work a typechecker has todo is the same and just runs of different nodes we need to determine what helpers we need and how they work.
• Wasm Alias Types, Currently we have a massive file that defines the type Defintions for all the wasm Aliases we use this works but sucks for maintainability, correctness and it is a lot of extra code in the compiler some things to consider are generating this from the spec or our wasmBuilder, or figuring out a way to define this in the language itself.