Each pass is like a Unix filter -- it takes input, processes it in some *very* well defined way, and produces output. Each pass communicates with other passes via in-memory buffers, so no mass storage is required.
Regarding mass storage requirements, though, you can have nanopass compilers on a Commodore 64 if you wanted, by reducing the size of the compilation unit. BSPL works on individual colon definitions, for example, and uses mere KB.
@vertigo I see, yes I divide up work into functions that operate on the entire compilation unit.
Mu has 27 'transforms': http://akkartik.github.io/mu/html/012transform.cc.html
SubX has 7 so far, but I added an additional notion of 'checks': http://akkartik.github.io/mu/html/subx/029transforms.cc.html
But the original nanopass paper describes designing a separate formally-defined language for each pass: https://www.cs.indiana.edu/~dyb/pubs/commercial-nanopass.pdf
(Unix pipelines also introduce concurrency and flow-control; I perhaps know too much for that analogy to be helpful.)
@akkartik I'm not sold on anything thsat recommends many different languages to basically treat successive transforms of an essentially equivalent graph. Proofs for every lttle lang seem way overkill to me, when you can reuse good old graph theory on any graph.
Then, that may be just me and my hammer seeing it all as nails. And linguistically oriented overengineering in a mathematical shape may also be somebody else's hammer. Different approaches, but I know which I'd follow.
NOTE: I'm *not* talking about the Nanopass Framework, which is a framework intended to automate the boilerplate of writing nanopasses, saving time in an educational context. I'm talking about the abstractions they are specific instances of.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!