The SHOP code is terribly confusing about what a "plan" is. Sometimes it's a list of actions interspersed with action costs. Sometimes those costs are removed (after a call to remove-costs). Sometimes it's only a list of normal actions (all internal actions -- prefixed with "!!" -- removed); you can get that with a call to shorter-plan).
Unfortunately, sometimes the shop code won't work if it has the wrong one of these, and the compiler can't help us find such errors.
I propose to add structure classes that wrap these different sequences and add function declarations that indicate which one of these various functions expect.
Inside SHOP3 proper everything is a full sequence (all actions, and costs) -- that code can remain untouched. But any code that manipulates a plan sequence should be fixed to a particular one of these structures, so that errors in plan-sequence manipulation (e.g., in plan-repair) can be caught by the compiler (at least SBCL's compiler) and fixed before run-time.
The SHOP code is terribly confusing about what a "plan" is. Sometimes it's a list of actions interspersed with action costs. Sometimes those costs are removed (after a call to
remove-costs). Sometimes it's only a list of normal actions (all internal actions -- prefixed with "!!" -- removed); you can get that with a call toshorter-plan).Unfortunately, sometimes the shop code won't work if it has the wrong one of these, and the compiler can't help us find such errors.
I propose to add structure classes that wrap these different sequences and add function declarations that indicate which one of these various functions expect.
Inside SHOP3 proper everything is a full sequence (all actions, and costs) -- that code can remain untouched. But any code that manipulates a plan sequence should be fixed to a particular one of these structures, so that errors in plan-sequence manipulation (e.g., in plan-repair) can be caught by the compiler (at least SBCL's compiler) and fixed before run-time.