Initial port for sCASP, a top-down interpreter for ASP programs with constraints

I’ve created a quick and dirty port for sCASP, a top-down interpreter for ASP programs with constraints. This system was created by Kyle Marple as sASP. Joaquín Arias Herrero added constraints and ported it from SWI-Prolog to Ciao. I’ve ported it back, using the Ciao emulation by @edison. As a result it is now a bit of a mess :frowning:

The purpose of this enterprise was to demonstrate the feasibility and understand the basics of the code. Depending on further evaluation it will hopefully evolve to a clean resource.

The port is available at GitHub - JanWielemaker/sCASP: top-down interpreter for ASP programs with constraints, where you also find pointers to the origin, articles, etc.

2 Likes

Status update

Fortunately SWI-Prolog Solutions has acquired partial funding to turn the sCASP port into a fully supported library. The first baby steps to refactor the software and turn it into a library that fully integrates into SWI-Prolog have been taken. Notably you can now load the software without dependencies on the Ciao emulation layer. This was seriously simplified using @edison’s "refactor" pack for SWI-Prolog. The recent addition to show_coverage/2 was triggered by @peter.ludemann’s post on coverage granularity and the need to get some more insight in which parts of the code are actually used and which parts are covered by the tests.

If you are interested in this project and can help, please contact me. I notably welcome tests. As there is partial funding, it is possible to get paid for your tests (depending on administrative limitations :frowning: )

1 Like

Dear Jan,

I’m interested in making sure that sCASP continue working in Ciao (and if possible other ISO Prolog systems). There are some future directions (like turning it into a library like CHR) that were already shared by other members of the Ciao development team.

Given the current changes in your github repository I am a bit afraid that this whole project may become a fork rather than a port. This happened many times in the past when complex libraries were ported from one Prolog to another one. Please remember that Ciao is actively developed and evolving Prolog system (“compatibility layers” not synchronized with our roadmap may become obsolete). We also strongly appreciate feedback and bug reports or performance reports when trying the original Ciao version (issues at GitHub - ciao-lang/ciao: Ciao is a general purpose, multi-paradigm programming language in the Prolog family).

Cheers,

Hi Jose,

That is right. The system will go through extensive refactoring and use a lot of the stuff that makes libraries integrate properly into the SWI-Prolog framework. That is unfortunate. I don’t see a good alternative though. Trying to keep it portable between the two systems, refactor it and add all the stuff needed to support modules, threads, etc. is going to be a nightmare. One option might be to make it completely or in part portable after this work. With “in part” I mean isolate notably those part of the code that have little to do with the Prolog environment and share those, for example using a simple :- include(File).

Hi Jan,

Yes, I agree that there are not many alternatives. Indeed the same would happen if I take one of the libraries or applications written for SWI and try to make them work nicely in Ciao. Surely, I would feel tempted to replace SWI-isms by Ciao-isms, make the code beautiful, clean, and super-fast (since I can write super-efficient code because I know every bit and of the engine and compiler and I can change it if needed).

Some languages like C/C++ managed to survive and evolve targeting many different architectures. It would be really good for the Prolog community if we could reach something similar at least with conditional compilation (perhaps with some non-standard additions). It is not necessary that all systems can implement all sCASP features, but at least making sure (with GitHub or GitLab CI scripts) that the system compiles and run on both systems, all the time, could be doable?

Cheers,

Hi Jan,

Is port supposed to be working only with 8.3?
I have issues running tests on 8.2
8.3 is working fine.

Is sCASP module aware, like the SLG resolution for XSB like tabling of SWI-Prolog?
(Right XSB like tabling in SWI-Prolog is module aware, isn’t it?)

I develop on the latest version :slight_smile: If you say it doesn’t work on 8.2, I believe that. I guess it should be possible to make it work. 8.4 shouldn’t be too far into the future :slight_smile:

As the work planned says, supporting modules is planned. And yes, tabling is supposed to support all dark corners of the module system.