"Compilation" of AT code

[GoogleCodeExporter]

Idea: enable lightweight compilation for AmbientTalk AST nodes by introducing a 
new method on 
AST objects:

Code impl_compile(CompilationContext ctx)

the CompilationContext could keep track of static lexical information 
(potentially enabling lexical 
addressing if it wasn't for "eval" and external slot definitions)

Code objects are simply lambda's, they have 1 main method (apply or maybe 
better 'run', to 
avoid confusion with ATClosure.apply). Compiled 'Code' is not first-class. 
Compilation could be 
on a per-method basis, where the top-level Code object is stored in an ATMethod 
instance.

The goal is not to have 'Code' be some sort of bytecode format. We should keep 
on using 
recursive descent on AST nodes (Java JITs are good at inlining those methods). 
But introducing a 
separate compilation step may enable more efficient evaluation by partially 
evaluating the 
generic evaluation routine based on statically known information.

Example: AGMethodInvocation.compile could partially evaluate the number of 
arguments it 
takes, then generate a custom version of meta_eval that only evals x arguments, 
where x is the 
statically known number of actual args provided to the AST.

Problem: if the custom routine then has to invoke the generic meta_invoke, the 
compilation 
process won't buy us much...

Original issue reported on code.google.com by tvcut...@gmail.com on 1 Dec 2009 at 7:18

[GoogleCodeExporter]

Forgot to mention: I envision the compilation process could be performed 
'in-line' in the ASTs, by generating 
anonymous inner classes for 'Code', enabling easy access from Code to the AST's 
child nodes.

Original comment by tvcut...@gmail.com on 1 Dec 2009 at 7:20