You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Julia's incrementally evaluated top level semantics make it rather
tricky to design a lowering interface for top level and module level
expressions. Currently these expressions are effectively *interpreted*
by eval rather than ever being processed by lowering.
However, I'd like a cleaner separation between "low level evaluation"
and lowering, such that Core can contain only the low level eval "driver
function". I'd like to propose the split as follows:
* "Low level" evaluation is about executing a sequence of thunks
represented as `CodeInfo` and creating modules for those to be
executed inside.
* Lowering is about expression processing.
In principle, the runtime's view of `eval()` shouldn't know about `Expr`
or `SyntaxTree` (or whatever AST we use) - that should be left to the
compiler frontend. A useful way to think about the duties of the
frontend is to consider the question "What if we wanted to host another
language on top of the Julia runtime?". If we can eventually achieve
that without ever generating Julia `Expr` then we will have succeeded in
separating the frontend.
To implement all this I've recast lowering as an incremental iterative
API in this change. Thus it's the job of `eval()` to simply evaluate
thunks and create new modules as driven by lowering. (Perhaps we'd move
this definition of `eval()` over to the Julia runtime before 1.13.) The
iteration API is currently oddly bespoke and arguably somewhat
non-Julian for two reasons:
* Lowering knows when new modules are required, and may request them
with `:begin_module`. However `eval()` generates those modules so they
need to be passed back into lowering. So we can't just use
`Base.iterate()`. (Put a different way, we have a situation which is
suited to coroutines but we don't want to use full Julia `Task`s for
this.)
* We might want to implement this `eval()` in Julia's C runtime code or
early in bootstrap. Hence using SimpleVector and Symbol as the return
values of `lower_step()`
We might consider changing at least the second of these choices,
depending on how we end up integrating this into Base.
0 commit comments