I don't know anything about how CL works but from your description it sounds like CL reads and compiles the whole file in one pass, whereas arc reads forms one by one, compiles each, and evals the result. Arc's 'load is based (indirectly) on 'sread which is scheme's 'read, which reads one expression at a time from the given input-port. Hence macro definitions at the beginning of the file are available for compilation into functions later in the same file.
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).
Right. It is as if the basic compilation unit for Arc were the expression, not the file. While this doesn't create problems for an interpreted implementation, this seems an efficency killer for native code compilers.
