Carl Mäsak

> it's the compiler's job to denormalize/analyze the code into target code, and the developers job to normalize/synthesize the source code In a stunning case of synchronicity, a few days...

> By being able to assume/lean on guaranteed optimization, macro writers can write smaller, simpler, more high-level macros; they can be "extravagant" in their use of high-level abstractions, because they...

> Three: look at that code example: > > ``` > let p1 y1 y2 = recv y1 Int @@ fun z1 → > recv y2 Int @@ fun z2...

Start with a "vanilla" object-level language. We abstract away from exactly which one. Now, either 1. Add staged compilation, or 2. Add macros and quasiquoting. What's the difference between the...

> Three: look at that code example: > > ``` > let p1 y1 y2 = recv y1 Int @@ fun z1 → > recv y2 Int @@ fun z2...

Just a quick thought: at the point when we have module imports, and the `Foo { ... }` instantiation syntax, it will also make sense to do `mymodule.Foo { ......

> In the fullness of time, a module being loaded is meant to be able to influence its loading context more than just installing a single symbol into it. The...

> In either case, a symbol gets installed in the lexical scope corresponding to the loaded module. This won't be enough. Take the use case of loading ranges as a...

I added the "needs-more-design" label to this issue. In my view, the next step is to identify the main use cases for modules (such as the `Range` case above) and...

> For example, Python (and Haskell) for this `from ... import ...` thing Coming back to this issue, I think this is where we should start. Possibly we can have...