Package-level declarations

A state change to be applied to an ExecutionContext after a it.unibo.tuprolog.solve.primitive.Primitive has run, rather than mutated directly by the primitive itself. Primitives attach zero or more SideEffects to their it.unibo.tuprolog.solve.primitive.Solve.Response (see it.unibo.tuprolog.solve.primitive.Solve.Request.replyWith), and the resolution strategy folds them, in order, over the context via ExecutionContext.apply -- each applyTo call producing a new, immutable ExecutionContext rather than mutating the one it receives.

A factory of SideEffects, offering one (often overloaded) method per concrete SideEffect subtype, as an ergonomic alternative to instantiating each subtype's constructor directly. Implemented by SideEffectsBuilder (which additionally collects the created instances), and available stand-alone via default.

An interface representing a manager for flow modifications that can occur to Prolog resolution process -- currently, just the effect of cutting (!/0) choice points.

A SideEffectFactory that also accumulates every SideEffect it creates into sideEffects, so a primitive can build up a list of side effects imperatively (calling factory methods for their effect on this builder) and then retrieve the whole list via build. This is exactly what it.unibo.tuprolog.solve.primitive.Solve.Request.replyWith's buildSideEffects: SideEffectsBuilder.() -> Unit overloads run against.