Bootstrapping

[Mercerenies]

Should we bootstrap GDLisp.gd from GDLisp code?

Pros:

• More internally consistent
• A good demonstration of the capabilities of the language
• Possible inlining opportunities that get rid of ad hoc call magic
• Several macros will be easier to write in GDLisp than in Rust

Cons:

• Slightly slower compilation times
• Have to restructure the integration tests so we don't recompile GDLisp.gd for every test
• Like seven pages worth of sys/declare statements to get the global names from GDScript into scope

[Mercerenies]

Current blocking issues:

• [x] Need to be able to control exports from a module (bb1cf8d1f8dddae9e3fd79096a7e79f8597807bc, 4cf9211a36610c40a7013e0b2b6e8fa5ca541310, and eb8d41d2f60d96da5bd5e03a7a36f99dec919e3d)
• [x] Need to be able to link call magic up to a defn declaration with some kind of compiler directive (80338d7)

[Mercerenies]

Steps in the bootstrapping process

1. [X] Translate built-in macros into straight GDLisp (1a193e2)
2. [X] Commit GDLisp.lisp to a new branch (844baff)
3. [X] Provide a way to perform a "minimalist" run, i.e. to run without incorporating the standard library at all. (4286e7b and 2f01196)
4. [X] Read the standard library from GDLisp.lisp rather than generating it from hardcoded Rust (576b279)
5. [X] Read macros from GDLisp.lisp rather than generating from Rust (4cbfb4f)
6. [X] Compile GDLisp.lisp as part of the build process (576b279)
7. [X] Set up test cases so they don't each have to compile the standard library separately (576b279)

[Mercerenies]

While not strictly blocking, #37 will make translating the built-in macros a lot easier.

[Mercerenies]

See branch bootstrapping for progress on this issue.

[Mercerenies]

I'll be using the blocks-bootstrapping label for any issues which are blocking progress on bootstrapping.

[Mercerenies]

As of cbf3a29, bootstrapping has been incorporated into master.