API and Modularization

[lorenzleutgeb]

I have been thinking about implementing an API for Alpha for some time. With the introduction of the Alpha class that acts as a facade for the whole system I made a first step. There's still a long way to go if the API should be taken seriously by application developers.

Prototyping Applications

I identified at least two applications that might use the API and act as guides in the API design:

1. Angry-Alpha (first I have to wrap my head around higher order predicates and eliminate them)
2. Wolpertinger (paper; the interesting part where it shells out to clingo is here; pointed out to me by @lukeswissman)

Modularization

In order to provide a smooth API, I think that we should modularize Alpha as follows:

• alpha-core: Contains grounder(s) and solver(s), but no main entry point. Depends on alpha-api.
• alpha-api: Contains glue code that allows instantiation of the Alpha system with given parameters, run it, and collect solutions. This includes a specification of all I/O, so we need Programs to go in and AnswerSets to go out, these would have to move to some package ac.at.kt.tuwien.alpha.api or similar that resides in this module. Depends on alpha-core.
• alpha-cli: Contains a main entry point that fiddles with arguments in order to run Alpha via alpha-api.

Further down the line we might want to extend this scheme, for example by writing a wrapper that integrates Alpha with Clojure. Such a wrapper would then depend on alpha-api as well.

While it might seem strange that these modules all depend on each other in a trivial fashion, we would have the following side-effects:

• Any option that should be exposed to the CLI must also be exposed through the API. No dirty hacks to circumvent it.
• In some bright future, one might generalize the alpha-api package in a way that it is suitable for a large range of ASP systems. Instead of alpha-core one could then depend on evenbettersolver which implements everything declared in alpha-api. It is conceivable to wrap clasp, so applications could switch out implementations.

Related Projects

• In Java:
  • asp4j uses Annotations
  • net.sf.tweety.lp.asp.solver.AspInterface declares an interface for solvers
  • lukeswissman/jclingo
• Jess which lead to JSR94
• DLV Java wrapper
• https://github.com/gaste/gringo-wrapper
• https://github.com/phohenecker/asp-wrapper
• https://github.com/egnwd/pingo
• https://github.com/Aluriak/clyngor
• http://cmt.math.unipr.it/jsetl.html
• JASP

Course of Action

• Evaluate whether asp4j can be re-used/forked/adopted.
• Modularize Alpha
• Consume the API from some applications, to see whether the API feels nice

[madmike200590]

@lorenzleutgeb Has there been any implementation work on that yet? Since I'm currently working on a number of projects that use (parts of) Alpha as a dependency (e.g. curriculator), I'd be highly motivated to move this forward, but since the issue is assigned to you, wanted to make sure I'm not duplicating stuff that might already be in progress..

[lorenzleutgeb]

I once attempted to split up the code, but that branch is hopelessly outdated. I took the liberty to reassign it to you.

Please take some time to rethink whether the modules I suggested, i.e. "core", "api", "cli", still make sense, and let's talk if you think that a different way of splitting would be more beneficial.

[madmike200590]

Thanks! Since we've currently got a few bigger PRs waiting to be merged, I can't do much right now anyway.. (as the splitting will probably wreak havoc on file histories).

The split I was thinking about would roughly be

• api -> basically Alpha.java plus everything in the commons package and the grounder/solver interfaces
• parsing -> the antlr-based parser, depends on api.
• core -> grounder/solver implementations, depends on api
• cli -> Main and config stuff that is only relevant when used as a commandline application, depends on api, core, parsing

The reason I'd split out the parser is that it would open up possibilities for metaprogramming (e.g. custom syntax constructs that can be rewritten to standard ASP) without having to depend on the full solver every time

[lorenzleutgeb]

Sounds good, except that I don't get why parsing/core would depend on api? I would expect it to be the other way round.

[madmike200590]

If API depended on core (and possibly parsing) you'd always have the full solver implementation in your classpath, regardless if you're actually using it.

For example, let's assume we have some ReST-Webapp that uses Alpha for some kind of business logic. The app consists of modules some-webapp and some-backend, where some-backend is a relatively simple library module that provides business logic and implements communication with the ASP solver and some-webapp is a SpringMVC project that implements ReST-controllers etc. and depends on some-backend. The point here is that the backend is not actually executable on it's own, so it only needs to depend on alpha-api which offers interfaces for grounder and solver components, but not the actual implementations. The webapp module in this example would then depend on alpha-api and alpha-core since it's the actual deployment artifact that needs a solver implementation as well as the API.
With the split suggested above, we'd ensure that only actual executables need to depend on the core module, thereby guarding against dependency cycles and also cases where we might have two different versions of alpha-core on the classpath because of different modules using slightly different versions of alpha-api (although that should be avoided anyway, of course..).

[lorenzleutgeb]

Right. Sorry.