Issue505

Title more aliases in driver
Priority wish Status resolved
Superseder Nosy List jendrik, malte
Assigned To Keywords
Optional summary

Created on 2014-12-17.21:13:45 by jendrik, last changed by malte.

Messages
msg10197 (view) Author: malte Date: 2021-03-18.14:36:30
Closing this as "won't do", as discussed today in the Fast Downward meeting. This doesn't mean aliases aren't interesting. But with the plans we currently have, we would probably implement this differently. In particular, we might eventually be able to write component factories in Python code, which would address this use case very nicely. But this first requires working on Python integration.
msg10178 (view) Author: jendrik Date: 2021-03-18.14:02:13
I think this issue can be closed, but I'll leave the decision to you, Malte.
msg5323 (view) Author: malte Date: 2016-05-10.12:13:37
See also issue655, msg5315 and following.
msg3964 (view) Author: malte Date: 2014-12-17.23:36:37
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.
msg3962 (view) Author: jendrik Date: 2014-12-17.21:13:45
This issue is part of the meta issue207 (revise search code). It deals with adding more aliases 
to the driver to prevent overfilling the searches with compositions. 

Example: astar(lmcut) --> eager(tiebreaking(sum_eval(g_eval,lmcut),lmcut)))

Malte, do you already have an implementation strategy in mind? Should we use regexes and custom 
code or a parser that parses aliases and generates search configurations?
History
Date User Action Args
2021-03-18 14:36:30maltesetstatus: chatting -> resolved
messages: + msg10197
2021-03-18 14:02:13jendriksetmessages: + msg10178
2016-05-10 12:13:37maltesetmessages: + msg5323
2014-12-17 23:36:37maltesetstatus: unread -> chatting
messages: + msg3964
2014-12-17 21:13:45jendrikcreate