3 Sep 2006 07:04
A quasi-interpretation code generation strategy for PEAK-Rules
I was kicking around a bit with the PEAK-Rules code today (after being away
from it for almost two months), and came up with an idea for how to manage
code generation more effectively than was possible with my previous ideas.
My original thought was that code generation would be doing the equivalent
of creating individual "switch" statements representing dispatch tree
nodes. This could potentially mean generating quite a large body of code,
to represent all possible dispatch locations, something like this:
switch type(expr1):
case X:
switch type(expr2):
...
case Y:
switch type(expr2):
...
In contrast, RuleDispatch has a short dispatching loop that walks a tree of
dictionaries, and has some code to get the next expression to be
computed. So instead of the dispatch tree being 100% code, it's 100% data.
What I realized today is that it's possible to make a 50/50 split between
code and data. I could create a lazily-expanded dispatch tree using
dictionaries, just like in RuleDispatch. But, the choice of what
expression to look up next, could be embedded in code, something like this:
node, dispatch_expr = start_node, start_expr
while not node.isleaf:
switch dispatch_expr:
case 1:
(Continue reading)
RSS Feed