Closed MaxOstrowski closed 1 year ago
Clorm creates wrapper/proxy classes clorm.clingo.Control
, clorm.clingo.Model
, etc, that wrap the corresponding clingo
objects. It then adds or overloads some member functions and passes through other member functions/attributes. But it only does this for the public API stuff.
However, Theory.on_model()
is trying to access the internal clingo.Model._rep
attribute, which doesn't exist for clorm.clingo.Model
.
We could try adding a clorm.clingo.Model._rep
attribute that points to the underlying clingo.Model._rep
attribute. I think this would work for your example. But I'm not sure if it is a good idea since the ._rep
stuff is an implementation detail and not part of the official clingo API.
BTW. As a hack you could change the solve
line to:
with ctrl.solve(yield_=True, on_model=lambda m: thy.on_model(m._wrapped)) as hnd:
This relies on an internal implementation detail of clorm.clingo.Model
(the ._wrapped
attribute). But I would be interested to know if this is the only thing that would need to change for a typical python clingo DL application.
Hi, that's exactly what I thought.
This is the only change I would need to do to get this example working. The question is whether it is better to rely on clingo's internal _rep
or clorm's internal _wrapped
. Maybe @rkaminsk has an oppinion on it ?
Maybe a m.clingo_model()
is nicer than a _wrapped
for this case ?
I would not use clorm.clingo.Control
. Instead, I would explicitly create a FactBase
from a model when needed.
Otherwise, I don't see an harm in making _wrapped
a public member in clorm. Maybe via a property to forbid changing it. This allows using the clorm.clingo.Model
in a type safe manner with a clingo.theory.Theory
.
I've also wondered whether having clorm.clingo.Control
is worth the extra complexity. When things work it only makes life a little easier, but when something breaks it makes it harder to work out what's gone wrong.
Anyway, I'm happy to add a property to access the underlying clingo object. A general name like wrapped
or wrapped_
would be simplest since I would only need to change the function that generates the wrapper. We just need to make sure it is a name that doesn't appear in the attributes of Control, SolveHandle, and Model.
Separate to this it might also be worthwhile creating a clorm.clingo.ControlDL
class that hides the details of importing and registering ClingoDLTheory
. A corresponding clorm.clingo.ModelDL
object would then provide a convenience function to access the DL assignment for that model.
I do not think that a clorm.clingo.ControlDL
class is necessary. The assignment can be easily accessed using mdl.facts(unifier, theory=True)
I tried to use clorm in conjunction with clingo-dl. This example snippet is the proposed way of loading difference logic into clingo:
I wanted to change this now using clorm by only changing two lines, the
Control
import and the control constructor:But I do get the following error:
What am I doing wrong ? Using: