Arc Forumnew | comments | leaders | submitlogin
Question: compile/run time distinctions in Arc
1 point by stefano 6001 days ago | 3 comments
I've noted only recently a difference beetwen CL and Arc. When you define a function,a macro that uses that function and you use that macro in the same file, if you load it in Arc everything works, but in CL you get an "unbound function" error, because during macroexpansion the function hasn't been loaded yet into the system, it has been only compiled. This is beacause functions in CL are actually built at run time and not during compile time. This makes me wonder how the read-compile-run cycle actually works in Arc. Suggestions?


3 points by conanite 6000 days ago | link

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.

This is the essence of Arc's 'load:

  (w/infile f file
    (whilet e (read f)
      (eval e)))
hth

-----

1 point by almkglor 6000 days ago | link

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:

  (def eval (e)
    ((to-free-fun:bytecode-compile:arc2b-compile e)))
... 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).

-----

1 point by stefano 6000 days ago | link

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.

-----