Macro system done in theory

too afraid to begin debugging, resting for a moment

notes/expr_refs.md

@@ -6,13 +6,13 @@ Reference loops are resource leaks. There are two primary ways to avoid referenc
 - Constants reference their constituent Expressions
 - Expressions reference Atoms
 - During evaluation, Constants replace their unbound names with Constants
-  - There is a reference cycle here, but it always goes through a Constant.
-    > **todo** A potential fix may be to update all Constants to point to a dummy value before freeing Trees
+	- There is a reference cycle here, but it always goes through a Constant.
+		> **todo** A potential fix may be to update all Constants to point to a dummy value before freeing Trees
 - Atoms reference the Systems that implement them
 - Atoms may reference Expressions that are not younger than them
-  - This link is managed by the System but tied to Atom and not System lifecycle
-  - Atoms can technically be applied to themselves, but it's a copying apply so it probably isn't a risk factor
+	- This link is managed by the System but tied to Atom and not System lifecycle
+	- Atoms can technically be applied to themselves, but it's a copying apply so it probably isn't a risk factor
 - Systems reference the Extension that contains them
 - Extensions reference the Port that connects them
-  - The Extension signals the remote peer to disconnect on drop
-  - The port is also referenced in a loose receiver thread, which always eventually tries to find the Extension or polls for ingress so it always eventually exits after the Extension's drop handler is called
+	- The Extension signals the remote peer to disconnect on drop
+	- The port is also referenced in a loose receiver thread, which always eventually tries to find the Extension or polls for ingress so it always eventually exits after the Extension's drop handler is called

notes/macros.md

@@ -17,11 +17,11 @@ Priority numbers are written in hexadecimal normal form to avoid precision bugs,
 - **32-39**: Binary operators, in inverse priority order
 - **80-87**: Expression-like structures such as if/then/else
 - **128-135**: Anything that creates lambdas
-  Programs triggered by a lower priority pattern than this can assume that all names are correctly bound
+	Programs triggered by a lower priority pattern than this can assume that all names are correctly bound
 - **200**: Aliases extracted for readability
-  The user-accessible entry points of all macro programs must be lower priority than this, so any arbitrary syntax can be extracted into an alias with no side effects
+	The user-accessible entry points of all macro programs must be lower priority than this, so any arbitrary syntax can be extracted into an alias with no side effects
 - **224-231**: Integration; documented hooks exposed by a macro package to allow third party packages to extend its functionality
-  The `statement` pattern produced by `do{}` blocks and matched by `let` and `cps` is a good example of this. When any of these are triggered, all macro programs are in a documented state.
+	The `statement` pattern produced by `do{}` blocks and matched by `let` and `cps` is a good example of this. When any of these are triggered, all macro programs are in a documented state.
 - **248-255**: Transitional states within macro programs get the highest priority
 
 The numbers are arbitrary and up for debate. These are just the ones I came up with when writing the examples.

notes/new_macro_model.md

@@ -42,9 +42,9 @@ Prioritised macro patterns must start and end with a vectorial placeholder. They
 Macros are checked from the outermost block inwards.
 
 1. For every name token, test all named macros starting with that name
-   1. If the tail is implicit, continue iterating
+	 1. If the tail is implicit, continue iterating
 2. Test all prioritized macros
-   1. Take the first rule that matches in the highest prioritized block
+	 1. Take the first rule that matches in the highest prioritized block
 
 Test all in a set of macros
 1. Take the first rule that matches in each block
@@ -75,26 +75,26 @@ Recursion has to happen through the interpreter itself, so the macro system is d
 - line parser `macro` parses a macro with the existing logic
 - atom `MacRecurState` holds the recursion state
 - function `resolve_recur` finds all matches on a MacTree
-  - type: `MacRecurState -> MacTree -> MacTree`
-  - use all relevant macros to find all matches in the tree
-    - since macros must contain a locally defined token, it can be assumed that at the point that a constant is evaluated and all imports in the parent module have been resolved, necessarily all relevant macro rules must have been loaded
-  - for each match
-    - check for recursion violations
-    - wrap the body in iife-s corresponding to the named values in the match state
-    - emit a recursive call to process and run the body, and pass the same recursive call as argument for the macro to use
+	- type: `MacRecurState -> MacTree -> MacTree`
+	- use all relevant macros to find all matches in the tree
+		- since macros must contain a locally defined token, it can be assumed that at the point that a constant is evaluated and all imports in the parent module have been resolved, necessarily all relevant macro rules must have been loaded
+	- for each match
+		- check for recursion violations
+		- wrap the body in iife-s corresponding to the named values in the match state
+		- emit a recursive call to process and run the body, and pass the same recursive call as argument for the macro to use
 		```
 		(\recur. lower (recur $body) recur)
 			(resolve_recur $mac_recur_state)
 		```
-  - emit a single call to `instantiate_tpl` which receives all of these
+	- emit a single call to `instantiate_tpl` which receives all of these
 - function `instantiate_tpl` inserts `MacTree` values into a `MacTree(tpl)`
-  - type: `MacTree(tpl) [-> MacTree] -> MacTree`  
+	- type: `MacTree(tpl) [-> MacTree] -> MacTree`  
 		_this function deduces the number of arguments from the first argument. This combines poorly with autocurry, but it's an easy way to avoid representing standalone tree lists_
-  - walks the tree to find max template slot number, reads and type checks as many template values
-  - returns the populated tree
+	- walks the tree to find max template slot number, reads and type checks as many template values
+	- returns the populated tree
 - function `resolve` is the main entry point of the code
-  - type: `MacTree -> MacTree`
-  - invokes `resolve_recur` with an empty `MacRecurState`
+	- type: `MacTree -> MacTree`
+	- invokes `resolve_recur` with an empty `MacRecurState`
 - function `lower` is the main exit point of the code
-  - type: `MacTree -> any`
-  - Lowers `MacTree` into the equivalent `Expr`.
+	- type: `MacTree -> any`
+	- Lowers `MacTree` into the equivalent `Expr`.