Defining a task that should always be performed before anything else

[ko56]

In my application, after the problem file is read in, and before anything else is done, there are some things that need to be pre-computed by tasks implemented by internal (!!) operators.
I have all these tasks in the method for the "initialization" task !!add-info-to-knowledge-base.
So the question is if there's a way to have !!add-info-to-knowledge-base automatically/implicitly executed before any other task. Instead of always having to specify it in the top-level method for each task.

[rpgoldman]

I'm afraid I don't fully follow the question. First of all, you talk about the method for !!add-info-to-knowledge-base but the "!" prefix indicates that this is a primitive task, so it should not have any methods.

As for getting a task to be done before anything else, one common trick is to encode the tasks in the state, and then have a single top level method that does any necessary set-up and then reads the tasks from the state. For example, see the method for add-new-goals in the blocks world domain definition. If you look at one of the problems in there, you will see that every problem has a single achieve-goals task. Since that single task provides a bottleneck, it lets the user force execution of any necessary set-up.

Alternatively, since problems take task networks, not just singleton tasks, as argument, you could just make sure every problem has a task something like (:ordered (set-up) <real-top-level-task>). This is easy to do if you generate your problems by program, using make-problem. I generally do that for any problem, because writing out full problems using defproblem is too much work (and because defproblem is a macro, it's difficult to stuff in computed content).

Feel free to ask follow-up questions or close this as answered if that's all you need.

[ko56]

The !! was a typo, it's actually just add-info-to-knowledge-base. (An aside before proceeding: if a task doit is implemented simply by an internal operator !!doit, is it good practice to name the task itself also !!doit?)
I have to think about the next two proposals.
What I do right now is for every top-level task, your (:ordered (set-up) <real-top-level-task>). But this is inconvenient, and causes problems if you forget to do it.

[rpgoldman]

The !! was a typo, it's actually just add-info-to-knowledge-base. (An aside before proceeding: if a task doit is implemented simply by an internal operator !!doit, is it good practice to name the task itself also !!doit?)

I don't know enough to say whether it's good or bad practice. I would say it is good practice if it helps you understand your domain better (especially after you have been away for a while!). I wouldn't say it's bad practice.

To be honest, I don't love the use of the ! to mark primitives, mostly because it conflicts with PDDL practice, and it relies on interned symbols (which cannot be garbage-collected). That said, I don't have any plans to change it because it's deeply ingrained in SHOP's code.

[rpgoldman]

What I do right now is for every top-level task, your (:ordered (set-up) <real-top-level-task>). But this is inconvenient, and causes problems if you forget to do it.

That is true, but as I said, I find that for any real applications (as opposed to test cases in files) I always end up writing one or more special-purpose functions that invoke make-problem, in which case all I have to do is put this pattern into the problem-creating function. In practice, I generally find that real problems require that the initial state be programmatically generated, typically because it's a combination of boilerplate contents (e.g., propositions that capture a fixed graph of connections) and additional facts that are specific to the individual problem and that are often computed or retrieved from an external source (e.g., locations of delivery trucks, packages and package destinations).

[ko56]

Yes, I just realized that I actually have such a function already, and the code uses it! The initialization or setup issue came about later, I had taken a break from the code, and I forgot about this function. So all is well, thanks.