[Gecode] Major design flaw and solution

[Christian Schulte]

Dear all,

we have been thinking (triggered by Gabor) for a while about what is the
right way to post a propagator. Here I stumbled about a major design flaw
but I think I have a solution and also have a sensible design guideline.

To get my message across clearly, first some notation (Wow!). By a propagate
method I mean the propagate member function every propagator needs to
implement. By a propagator post function I refer to the static member
function every propagator should provide for posting a propagator of that
class. By a post-function I refer to the functions which are used by clients
of Gecode to create propagators (they are implemented in terms of propagator
post functions).

Let me tell what the prupose of the two different post functions are:

POST_FUNCTION

	As said, serves as interface to the clients of Gecode. Here, typical
tasks are preprocessing of arguments and dispatch on the level of
consistency.

PROPAGATOR POST FUNCTION

	They are propagator specific (static). Their purpose is to create a
propagator, if needed. Also, take care of special cases such as creating a
special variant of the propagator, enforcing some invariants on variables
required by the propagator or avoiding propagator creation at all (just do a
tell, for example).

	Propagator post functions are used for two purposes: one is to
provide the means to implements post-functions. Secondly, they are used for
posting propagator inside the propagation functions of other propagators
(think of a refied propagator).

	A propagator post function is the ONLY way to create a propagator
(so I actually declared all constructors protected!), as they are the guys
to ensure the right invariants PRIOR to propagator creation proper.

	HERE IS THE FLAW: A PROPAGATOR POST FUNCTION CAN FAIL (AND IT DOES).
If you invoke a propagator post function in a propagation function you are
fucked: failure goes unnoticed. And I don't want to hack that, it is
important that failure in posting also is transferred the same way as
failure in tells.

So what needs to be done is to have propagator post functions return a
status. That is what I did (and what I will check in):

Introduce a new enumeration type PostStatus with values POS_NONE and
POS_FAILED (that is instead of having static void post(...) we get static
PostStatus post(...)).

To disambiguate from PropStatus values I renamed them from PS_* to PRS_*.

The macro FAILCHECK is gone. For replacement the following macros are used
(all macros need to start with GECODE_ anyway ;-( )

GECODE_CME_PROP(me): That is the former FAILCHECK: check whether tell has
failed and forward status. During propagation.

The other then are straightforward (check for kernel/macros.hh):
GECODE_CME_POST(me): Tell inside propagator post function.

GECODE_CME_SPACE(me): Tell inside post-function.

The latter two guys should make life much easier (hi Gabor!).

The same set exists now also for propagator post functions:
GECODE_CPOS_PROP, GECODE_CPOS_POST, GECODE_CPOS_SPACE



The names may suck, but that we can fix later.

What still needs to be done, is to convert everything into using the above
discipline.

Not that clear the Email, I am tired. Does it make sense?

Cheers
Christian

--
Christian Schulte, http://www.imit.kth.se/~schulte/