From the last SIP meeting:
Conclusion: The SIP is delayed until Olaf gathers the team and has some new updates to share with the Committee.
We have a team of contributors:
- myself, project lead working for the Scala Center on proposal SCP-014: towards "non-experimental" macro system (my interpretation: portable and robust macros).
- Liu Fengyun, on behalf of the Dotty team.
- Mikhail Mutcianco, on behalf of Jetbrains.
We are in a dialogue with:
- Eugene Burmako
- Scala community via contributors.scala-lang.org
- Heather Miller
- Ryan Culpepper
- Adriaan Moors/Jason Zaugg, Scala compiler team
My role as I see it is to
- communicate with involved parties,
- research the macro landscape/ecosystem,
- coordinate engineering efforts on the new macro system so that it 1) addresses existing pains and 2) at least something is delivered within a timeline of 4-6 months.
What I'd like to get out of this meeting is to present our findings from the past 3 weeks, give my personal recommendations and collect your feedback on how to prioritize our upcoming work.
- Scoping changes are a concern.
I think there are roughly four categories of macros grouped by features they require from the macro system: code transformation, code generation, inlining for performance reasons, and "linting".
Example:
| transformation | generation | inline | linting | |
|---|---|---|---|---|
| scala-async | x | |||
| ScalaTest assert | x | |||
| f"" interpolator | x | |||
| Json.serialize[T] | x | |||
| ScalaTest Position | x | |||
| sourcecode.Name | x | |||
| log4s logger.info | x | |||
| Refined Positive | x |
We can view these categories by the features they require:
| transformation | generation | inline | linting | |
|---|---|---|---|---|
| Inspect trees | x | x | x | |
| Inspect types/symbols | x | x | ||
| Construct trees | x | x | ||
| Report errors | x | x | x | x |
| Solvable with SIP-28 | x |
There are still many hard/open/unsolved problems, most notably:
- splicing untyped tree under typed trees causes breaks typer invariants, causing compiler crashes
- splicing typed tree under untyped trees causes owner chain corruptions, causing compiler crashes
Several techniques have been explored to solve these problems:
- c.untypecheck, breaks for certain tree nodes due to non-idempotency
- c.typecheck or manually construct typed trees, requires expertise from macro authors and can still cause cryptic errors in later phases.
- automatic repair of owner chains, works for some limited macros
- automatic typechecking of spliced untyped trees, little explored
These solutions have different trade-offs with regards to
- feature support
- portability
- breaking changes with existing macro ecosystem
There seem to be no roadblockers for supporting macros that do no tree inspection, only untyped tree construction. Code generation macros cannot change