Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do you plan to improve this library? #21

Open
guicho271828 opened this issue Jun 13, 2023 · 10 comments
Open

Do you plan to improve this library? #21

guicho271828 opened this issue Jun 13, 2023 · 10 comments

Comments

@guicho271828
Copy link

I have a code base that cleans up the parser (mainly type annotations) and a separate branch that supports action costs.
Is this repo open for pull-requests like this?

@maltehelmert
Copy link
Contributor

maltehelmert commented Sep 20, 2023

Dear Masataro, apologies for the lack of reply so far. The maintenance status of the project is not very clear. It is not very actively maintained. In practice it seems that @jendrikseipp and I are the ones that answer most questions, and Jendrik has taken the bulk of the maintenance work in recent years. Jendrik, what do you think about Masataro's question? I think improvements along those lines would be nice in principle.

@jendrikseipp
Copy link
Contributor

Hey Masataro, thanks for the suggestions! Type annotations would be great to have, but we'd need to also have tests for them, so that we know they're in sync with the code (probably using mypy). Action costs I'm less certain about, since this is a feature that is often omitted for teaching students about planning. It also depends on how much more complicated this change makes the code.

@guicho271828
Copy link
Author

Noticed your replies now. I am slow too :)

Yes, I use mypy.

The current parser is not designed for modularity and yes, adding action costs was a significant change.

I also feel the current design is a bit over-engineered (Visitor pattern), but this is another story and I do not address this.

@guicho271828
Copy link
Author

I hope to see a refactoring that includes mixins for parsing each extension, e.g., action-costs, cond-effects, numeric variables, etc. Consider a code like this:

class STRIPS(Parser):
   ...
class DerivedPredicates(Parser):
    ...
class CondEffect(Parser):
    ...
class Probabilistic(Parser):
    ...
class Numeric(Parser):
    ...

class NumericProbabilistic(Numeric, Probabilistic, STRIPS):
    pass

@guicho271828
Copy link
Author

@cjmuise Suggested replacing the parser to https://github.com/AI-Planning/pddl

@guicho271828
Copy link
Author

@haz

@maltehelmert
Copy link
Contributor

I also feel the current design is a bit over-engineered (Visitor pattern), but this is another story and I do not address this.

pyperplan is an undergrad student project, so its developers did not have much software engineering experience.

@jendrikseipp
Copy link
Contributor

Given that this project should strive to remain simple, I think action costs are out of scope. And there's value in having no external dependencies, so I'd be reluctant to consider adding an external parsing library. But as I said, type annotations with mypy tests sound like a great idea for making the project more accessible to students.

@meneguzzi
Copy link

It seems multiple people are keen on having an entire planner written in Python with pretty software engineering, as I've had similar queries in the infrastructure I use for my own undergraduate planning assessment (and the very basic parser we developed in my group). Perhaps there's an opportunity for a community project here. An ICAPS planning in Python hackathon? 🥇

@jendrikseipp
Copy link
Contributor

Regarding Python planners: the Fast Downward team is working towards adding a Python API to the planner. And the Mimir planner, which is also implemented in C++, already has a Python API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants