They are similar, although SABR tends to be more verbose as it keeps a polynomial relationship between size of SABR programs and the underlying SAT. It can in some ways be easier to reason about, but that's sort of in the eye of the beholder. In the past I've prototyped simple examples in SABR then written a generator in python for the full program.
Here's a great resource for those interested in constraint programming: http://www.hakank.org
There's the built in construct of transitions which isn't in this example that is preloaded into SABR, but one could easily enough write the restraints required for this in clasp.
SABR envisions the universe as the "Board" and it has a given size consisting of elements and each element can have a specific state as defined by "Symbols". Then you can build on that to say what is legal for a theoretical set of elements, and how that set can transform over time, then you can define which of the Board elements correspond to the defined theoretical set.
Its way more opinionated than most other constraint programming languages, which can be mind bendy.
Here's a great resource for those interested in constraint programming: http://www.hakank.org
Sudoku examples: SABR: http://www.hakank.org/sabr/sudoku.tb
ASP: http://www.hakank.org/answer_set_programming/sudoku.lp
There's the built in construct of transitions which isn't in this example that is preloaded into SABR, but one could easily enough write the restraints required for this in clasp.
SABR envisions the universe as the "Board" and it has a given size consisting of elements and each element can have a specific state as defined by "Symbols". Then you can build on that to say what is legal for a theoretical set of elements, and how that set can transform over time, then you can define which of the Board elements correspond to the defined theoretical set.
Its way more opinionated than most other constraint programming languages, which can be mind bendy.