Alex Knauth

They currently work like `module` and not `module*`. Modules cannot refer to definitions from their enclosing modules, but definitions in an outer module can refer to submodules.

PS: Even with a form that behaved more like `module*`, the `mod` form should ideally stay the same. It wouldn't be `(def-module M (mod ....))` vs. `(def-module M (mod* ....))`,...

Would you rather have a function like `call-with-no-elaborate-pass`, or an optional extra argument like `(local-expand+elaborate .... #:reset? #true)`?

Are sets "intended" to be indexable by natural number even though there isn't a definitive order of elements? That's what's causing the test failures

It would require a change to both `livesplit-core` and `asr`, where the change to `livesplit-core` would need to come first. That's why #747 is there as a PR to `livesplit-core`...

I do need to update it to fix a conflict with the Event System changes to `livesplit-core`. Edit: now rebased and fixed Edit 2: still working on an issue with...

While fixing that I also updated companion branches on both `asr` and `LiveSplit.AutoSplittingRuntime` to be compatible with #747.

That would fit fine in this package. Although it won't be able to print out the expression of the callsite like `#R` would, and I'm not sure how a user...

So `#lang debug/no-output` isn't good enough because it's determined at compile time on a per-file basis?

Yes. I *am* trying to preserve macro transformer values so I can use them at run-time in a Repl. My current solution works in situations where I run and compile...