Fri Sep 12 12:46:53 CEST 2008
Actually, if I only knew the stack effect of a macro for all literal
arguments, it would be straightforward to simulate it during live
target interaction. This could get rid of all explicitly coded
simulation in live/command.ss making the command frontend less
dependent on extensions (all semantics would be encoded in macros).
* annotate macros with stack effect (pre-checks)
* let it operate on data directly (either lazily, or copy whole stack)
I.e. for +:
1. copy the whole stack (1 2) -> ([qw 1] [qw 2])
2. apply macro -> ([qw 3])
3. success? replace stack -> (3)
Copying the whole stack isn't too much communication overhead, and
it's easiest to implement.
The change needs to be made in live/target-lang.ss in
'target-interpret. This needs to change to full symbolic
interpretation relative to the compiler namespace: map-id needs to do
Maybe the the undefined symbol hook for the target/xxx namespace
reference should be added to then try the macro/xxx namespace?
It's simpler than that: at compile time, check if the name is defined,
otherwise compile a macro/xxx reference. Use 'identifier-binding
See next posts.
The trouble is that writing a generic simulator is a lot of work.
Probably not so much the infrastructure, but entering all the
processor specific data. Looks like I'm better off with just keeping
the current simplistic interpreter + a macro evaluator.