Devlog

These are my daily notes and internal conversations during development. They may be helpful to understand the larger context of decisions that were made, and how I learned and explored while building.

Devlog < 2023 < April < 26

| by date | | thread: co |

Diving back in after a busy few weeks.

---

Once we have a context loaded with linked symbols, it is ready to import all of the symbols. importing requires us to first render all of local sources into symbols. rendering a routine means converting all routine labels into hashes, and expanding all macros, whether hash or label. rendering a macro means expanding all macros it contains.

If we render macros first, we don't need to recursively render them when rendering routines. so first we go through all the macros, rendering the sources into symbols. we can keep a map of source names -> hashes so know what was rendered. then we can use that map to import the into the library.

---

So actually, we really have to be able to convert source to symbol in any order, since macros and routines can both depend on any other macros or routines. So there’s no order involved, and both “export” functions have to be able to recursively export other symbols if they encounter an unexported one. There is also a difference between “exporting” a macro to the library, and “rendering” it into byteco. When we export a routine, we are expanding all source and symbol macros (process is identical), replacing all routine name references with hash references, and maybe still culling out absolute anchor and padding use?

| thread: co | | by date |