I have to step on the brakes here a little bit.
The first question is not how to implement but whether we want to do this at
all. This requires building consensus among the wider downward-dev group.
There are certainly downsides to the idea. It would become next to impossible to
manually invoke the search component with, say, an A* search, and that
complicates things that are easy now, such as setting up debugging invocations
of the search component with certain parameters in an IDE. It can be a
significant drawback to have to go through a script for everything.
The example also shows that this is not so trivial to get right: it would
compute lmcut twice on every state and hence almost double the runtime. Anything
based on pure text substitution without a bit of knowledge about the semantics
would have a problem like this; we would at least need something like a simple
hygienic macro facility to really express the kinds of substitutions we want to
do (in this case, something like "astar(X) => --heuristic <new heuristic symbol
S>=X eager(tiebreaking(sum_eval(g, S), S)))" if I recall the details of A*
correctly; perhaps this is still missing a progress_evaluator spec?)
To me, the major big issue is how to solve the documentation problem. Losing the
existing documentation of A* (and anything else that becomes macro-fied) would
make this feature a non-starter, so we need to come up with a strategy of how to
integrate this into our documentation building infrastructure. This is probably
much more difficult than the substitution feature itself.
Regarding the implementation strategy, I'm with the famous JWZ quote in cases
like this: 'Some people, when confronted with a problem, think "I know, I'll use
regular expressions." Now they have two problems.'
Macros of this kind need knowledge of syntax and must perform their processing
on the level of abstract syntax trees, not on the level of strings of characters.
|