You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: