I like the idea of using Loki for detecting duplicate planning tasks! Can you add a short guide to the README that shows how to do this?

Maybe this should be a separate discussion, but have you thought about canonicalizing PDDL files, i.e., sorting everything in them, to detect more duplicates? And possibly even canonicalizing all (object, action, etc.) names?

I have troubles printing the parameter list of a Predicate because the "object" type should not be printed if :typing is disabled. Furthermore the print function should not take additional arguments since we want to overload the operator<< of sd::ostream.

Another use case for Loki could be to pretty-print input PDDL files. Many of them have quite some strange format. The tricky thing here is to preserve comments. Not sure the parser library can handle that. But maybe there are cases where there are no comments or comments don't need to be preserved.

Objects fluents are rarely supported by the planning community. Are people interested in using them? Are they deprecated?

To further improve the readability of the grammar we should move grammar rules that are used in the domain and the problem into common. The resulting domain and problem grammar will only contain the relevant parts then and will be easier to read and understand.

Option 1: throw an error
Option 2: simply filter them out using sets

The problem is the following. A ast::Name is a word over alpha numerical characters starting with a alphabetical character and a ast::Variable is ast::Name with prefix ?. Clearly, both are syntactically different. The syntactic parser will just fail at a position where it expects a ast::Name but a ast::Variable was given. Currently the error might be some thing like: Expected ')', which I find is a bit unsatisfying. If we would instead parse a node ast::NameOrVariable represented as an alternative and get a successful parse, we could decide to throw a more meaningful error in a later parsing step (syntactic or semantic parsing).

I think this should be the responsibility of the syntactic parsing: Ideally, we would like a boost syntax parser with only expectation operations (>) because they allow us to report a meaningful errors. When an expectation operation fails, an exception is thrown with a meaningful error message and position in the input stream depending on the parser that failed, e.g., "Expected a variable or a name". This requires splitting the syntax parser into an iterative process. Important question: can we parse only the most basic structure first, e.g., for each opening parenthesis there must follow zero or more characters, must follow closing parenthesis, i.e., node_def = lit('(') > *text_or_node() > lit(')'), text_or_node_def = (*char_ | node). I think the answer is yes. Furthermore, can we then refine the AST that we get to obtain a more concrete AST with same idea of using expectation operations only? Probably yes, but not so sure how easy that is because when the nodes are more abstract, they may contain many alternatives (|) and therefore, a resulting blowup in the number of AST nodes and parsers.

This will require a lot of rework in the syntactic parser but should be fully separate from the semantic parsing that we currently got since the resulting AST will be the exact same as the AST that we currently have. However, it is important to ensure that this will not cause changes on other sides of the code since this is highly relevant for the goal of the project.

The current PDDL data structure is very powerful and convenient. However, we want to provide a better abstraction that is closer to zero cost. The main issue is the usage of std::shared_ptr in the PDDL data structure which is not zero cost when copying: requires a redundant atomic increment and requires std::mutex locks to ensure that the ref count is synchronized a cross several threads.

One way to address this limitation is to translate the shared_ptr based data structure (shared_PDDL) to an analogous data structure based on a combination of std::unique_ptr and raw pointers. Since PDDL objects are const, this solves the thread synchronization problem.

Another step towards zero cost abstraction, would be to provide a non fragmented indexing scheme for each PDDL type. This can be easily addressed by splitting the PDDL factory into one for each type. To ensure non fragmented indices after user define compilation, we can provide a function to reparse the result of the compilation. To make the usage of indices safer, we could use a handle-like type for each PDDL type.

There are good reasons to move towards value semantics as opposed to pointer semantics for storing PDDL objects. 1) We don't need virtual bases classes but we currently use them, e.g., for conditions, effects. 2) Cache locality: with a combination of handles and views we can get better cache locality. A PDDL object will then be composed of Views to make it easy to access the data members.

A Handle could be implemented as follows:

template<typename T>
class Handle {
    private:
        int m_identifier;
    
    public:
        Handle(int identifier) : m_identifier(identifier) { }

        int get_identifier() const { return m_identifier; }
};

A View could be implemented as follows:

template<typename T>
class View {
    private:
        Handle<T> m_handle;
        const VectorByHandle<T>* m_vector;  

    public:
        View(Handle<T> handle, const HandleVector<T>& vector) : m_handle(handle), m_vector(&vector) { }

        Handle<T> get_handle() const { return m_handle; }
        const T& get_data() const { return (*m_vector)[m_handle]; }
};

A VectorByHandle could be implemented as follows:

template<typename T>
class VectorByHandle {
    private:
       std::vector<T> m_vector;

    public:
        // delete copy/move to not invalidate the pointer in a View
        VectorByHandle(const VectorByHandle& other) = delete;
        VectorByHandle& operator=(const VectorByHandle& other) = delete;
        VectorByHandle(VectorByHandle&& other) = delete;
        VectorByHandle& operator=(VectorByHandle&& other) = delete;

        const T& operator[](Handle<T> handle) const { return m_vector[handle.get_identifier()]; }
};

During parsing, we can collect additional information such as: what requirements, objects, predicates, function skeletons, etc. were actually used and provide a errors to the user.