Resources that use constraints instead of tokens have several advantages in terms of efficiency and simplicity. Currently only Reusable has a constraint-based version (CBReusable), we need to provide constraint-based versions for the other Resource types: Reservoir and Unary.

From Paul:

Will these new ones be in addition to the current types of resource? So the old ones will still be available?

Can you detail the efficiency advantages? Fewer timepoints?

yes, this will be in addition to the current resource types, the same way that Reusable and CBReusable co-exist today.

main advantages of constraint-based resources off the top of my head: efficiency in time and space: - less tokens, timepoints and propagation in the constraint network

simplicity: - resource violations can be reported consistently with the native mechanism implemented in europa, they don't require special treatment - if we want to bring resources into bounds propagation, it can be done consistently within the constraint engine framework - search algorithms can be written more naturally/concisely if all violations are explicitly related to constraints