Freezing Variables
rkaminsk opened this issue · comments
I want to extend the clingo interface mark a variable as frozen during propagator initialization. Currently, clingo already has a class with some extended functionality, which has access to clasp's facade. What do you think is best? Use the shared context to mark the literal as frozen or add a method to the ClingoPropagatorInit class? In the former case, given a solver literal lit, would
ctx.setFrozen(Clasp::decodeLit(lit), true);be safe enough for the API?
Furthermore, variables of literals added via addWatch should be frozen automatically. This is probably something that clasp should do automatically behind the scenes.
I created a clasp branch with the necessary changes. However, in terms of LOC, it would actually be easier to handle everything in ClingoPropagateInit as this class already has full access to the relevant Clasp::SharedContext while Clasp::ClingoPropagatorInit has not.
I.e. one could add something like:
void ClingoPropagateInit::freezeLiteral(Lit_t lit) {
facade_().ctx.setFrozen(Clasp::decodeVar(lit), true);
}and then call freezeLiteral() from the two addWatch() overloads. Of course, this wouldn't do the (stupid) dance of balancing out addWatch/removeWatch calls.
Anyhow, let me know which version you'd prefer so that I can adjust the ticket/branch accordingly.
@rkaminsk Is this issue still relevant?
Yes, let's use your implementation. I do not know why. But this is the third time I am replying to this issue but the comment never appears.