AbstractPrologSolver
Base implementation of every :solve-prolog it.unibo.tuprolog.solve.Solver/it.unibo.tuprolog.solve.MutableSolver (PrologSolver and MutablePrologSolver, both internal, are the only two concrete subclasses; instances are normally obtained through PrologSolverFactory, which is what the Solver.prolog property resolves to).
What this class actually contributes over AbstractSolver is solveImpl: turning a goal into a Sequence of Solutions by driving the it.unibo.tuprolog.solve.prolog.fsm.State finite-state machine described by the :solve-prolog state-machine explanation page. Concretely, it builds the root PrologExecutionContext for the query, wraps a fresh it.unibo.tuprolog.solve.prolog.fsm.StateInit into a SolutionIterator (via the abstract solutionIterator hook, which lets subclasses choose a plain or hijackable iterator), and exposes that iterator as a lazy Sequence -- so pulling the next Solution from the sequence is exactly what drives the state machine one step further, rather than eagerly computing every solution up front. currentContext is kept in sync with the state machine's progress via updateCurrentContextAfterStateTransition, which every SolutionIterator created here is wired to call after each transition.
Running resolution as an explicit loop over it.unibo.tuprolog.solve.prolog.fsm.State values, instead of host-language recursion, is what lets a resolution step be paused, resumed, or inspected without unwinding a JVM/JS call stack, and sidesteps host stack-depth limits for deeply recursive Prolog programs (the "call stack" here is the PrologExecutionContext parent chain -- ordinary heap data).