retoor/orchid
1
0
Fork 0
forked from Orchid/orchid
Code Pull Requests 1 Activity

temp commit

Browse Source
This commit is contained in:
Lawrence Bethlenfalvy
2025-07-12 00:46:10 +02:00
parent 1868f1a506
commit fe89188c4b
60 changed files with 1536 additions and 709 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
SWAP.md
View File

@@ -1,12 +1,10 @@
## Async conversion
Since the macro AST is built as a custom tokenizer inside the system, it needs access to the import set. On the other hand, import sets aren't available until after parsing. Need a way to place this order in a lexer without restricting the expression value of the lexer.
consider converting extension's SysCtx to a typed context bag
align fn atom and macros on both sides with new design. No global state.
The daft option of accepting import resolution queries at runtime is available but consider better options.
## alternate extension mechanism
The Macro extension needs to be in the same compilation unit as the interpreter because the interpreter needs to proactively access its datastructures (in particular, it needs to generate MacTree from TokTree)
The STD system will have a lot of traffic for trivial operations like algebra, stream IO will likely not be fast enough. A faster system is in order.
Ideally, it should reuse `orchid-extension` for message routing and decoding.
@@ -14,10 +12,8 @@ Ideally, it should reuse `orchid-extension` for message routing and decoding.
## Preprocessor extension
Must figure out how preprocessor can both be a System and referenced in the interpreter
The macro system will not be privileged, it can take control from the interpreter via a custom top-level "let" line type.
Must actually write macro system as recorded in note
At this point swappable preprocessors aren't a target because interaction with module system sounds complicated
Check if any of this needs interpreter, if so, start with that