Note by the way that this is the problem that macros in arc2c face: in a single compilation unit, a function defined earlier must be callable from a macro actually used later ^^. Also, to preserve as much of Arc's semantics as possible, a macro could be redefined in a single compilation.
^^
SNAP would sidestep this largely by simply using bits of arc2c only as part of eval - basically eval is simply:
... where arc2b-compile is the bits of arc2c modified to emit the bytecode as a list of symbolcodes, bytecode-compile accepts that list and returns an opaque abstract bytecode-sequence object, and to-free-fun creates a free function (one without any closed variables, i.e. all free variables are globals).
So SNAP will compile expressions one at a time.
However arc2c reads the entire compilation as one big expression, hence the difficulty. It may be possible to modify it so that it compiles files one expression at a time though; possibly this could be done by targeting to a bytecode, and then writing a bytecode-to-c transformer, but it loses some global optimizations (oh well).
