Prolog Laravel Package

Technical Evaluation

What the package is. trismegiste/prolog is a pure-PHP implementation of a Prolog engine built around the Warren Abstract Machine (WAM): Prolog source clauses are parsed and compiled to WAM instructions, which are then executed by a PHP-implemented virtual machine (unification, backtracking, choice points, cut). It is not a binding to SWI-Prolog or FFI — it is an interpreter written in userland PHP.

Architecture fit.

• Genuine fit only where declarative search is the value: rule engines/expert systems, eligibility and policy validation, DCG-based parsing, symbolic reasoning, planning/scheduling prototypes.
• It is not a substitute for a rules DSL for simple conditionals; symfony/expression-language or a lightweight rules engine will be cheaper to own, test, and staff.
• In a Laravel app it belongs behind a port/adapter boundary (RuleEngine interface) so the inference core is swappable for a SWI-Prolog sidecar if scale or correctness demands it.
• Domain logic migrates into .pl files — that is a governance decision, not just a technical one: rule authorship, review, and versioning move outside normal PHP code review.

Integration feasibility.

• Composer-installable, namespaced (Trismegiste\Prolog), no PHP extensions or compiled artifacts required — deploys on standard Laravel hosting, containers, and restricted environments where exec/FFI to SWI-Prolog is unavailable.
• Integration surface is small: instantiate an engine, load clauses, issue a query, read bindings. A thin service wrapper plus a service provider is a sub-day effort.
• Friction points to verify early: PHP version constraint vs. the project's Laravel/PHP matrix, PSR-4/PSR-12 conformance, presence of a LICENSE file and its terms (GPL vs. MIT materially changes the decision for a proprietary product), and whether composer.json declares sane stability and autoload config.

Technical risk.

• Adoption/bus-factor risk (high). 32 stars, effectively single-maintainer, no evidence of a commercial backer. Assume you may inherit maintenance.
• Performance risk (high). WAM instruction dispatch in userland PHP is typically one to three orders of magnitude slower than native Prolog. Acceptable for small knowledge bases and low query volume; unacceptable for per-request inference over thousands of facts.
• Resource-exhaustion risk (high). Backtracking grows the choice-point/environment stacks; left-recursive or unbounded rules can run until max_execution_time or memory_limit kills the worker — a fatal error, not an exception, so it is not catchable in-request.
• Semantic-conformance risk (medium). Expect a subset of ISO Prolog. Cut, negation-as-failure, arithmetic, and error-term behavior must be validated against your rule sets rather than assumed.
• Correctness-debugging risk (medium). When a query returns false, distinguishing "no solution" from "malformed rule" from "unsupported built-in" is often manual. Traceability from a failed query back to a specific clause is the main developer-experience gap.
• Security surface (low–medium). If end users or tenants can supply Prolog text, you have handed them a general-purpose execution and DoS surface. Treat authored rules as code, not data.

Key questions to answer before commitment.

1. What is the license, and is it compatible with closed-source distribution?
2. Which PHP versions are supported, and is there a CI matrix and test suite with meaningful coverage?
3. What is the supported Prolog subset — cut, NAF, arithmetic, DCGs, modules, findall/bagof, string handling?
4. Is the engine stateless/reusable across requests, or does it accumulate internal state that leaks between resolutions?
5. Can compiled clauses be serialized and cached (deploy-time compilation), or must parsing happen per request?
6. Are there configurable limits — max inference steps, max depth, memory ceiling — or must the caller enforce them via pcntl_alarm/supervisor timeouts?
7. How are Prolog errors and exceptions surfaced to PHP callers?
8. Who owns the rule base, and what is the review/versioning process?

Integration Approach

Stack fit.

• Bind a PrologEngineFactory in a PrologServiceProvider; expose a PrologService that owns clause loading, query execution, and result normalization into plain PHP arrays/DTOs.
• Store .pl sources in resources/prolog/ (versioned, code-reviewed) and publish config via config/prolog.php for paths, step limits, and cache TTL.
• Wrap every invocation in a try/catch plus a hard step/time budget enforced by the wrapper — never let an unguarded query reach a web request path.
• Route non-trivial inference through queued jobs (ShouldQueue, with $timeout and $tries), returning results via broadcast or polling. This converts fatal-error risk into a retryable job failure.
• Optional Artisan commands: prolog:compile (parse and serialize clauses for caching), prolog:query (REPL-ish debugging for developers and rule authors).

Migration path.

• Start with a bounded, read-only reasoning module — one well-scoped decision (e.g. eligibility determination, configuration validation) — never a rewrite of existing domain logic.
• Put the existing PHP implementation and the Prolog implementation behind the same interface, run them in shadow mode, and diff outputs on real traffic before cutting over.
• Keep the interface implementation-agnostic so the fallback (SWI-Prolog sidecar over HTTP, or a PHP rules engine) can be dropped in without touching call sites.
• Strangler pattern: expand Prolog's footprint only after each module has a proven golden-file test suite and a measured performance profile.

Compatibility.

• Verify the package's php constraint satisfies your Laravel version's floor (Laravel 10/11 already require 8.1/8.2). Dependency conflicts are unlikely given it is standalone, but confirm it does not pull in deprecated or abandoned transitive packages.
• Check for global/static state and ini_set side effects that could interfere with Octane or long-running workers; if the engine is not stateless, do not register it as a singleton under Octane — use a scoped binding or per-job instantiation.
• Confirm exception types are PSR-friendly and will not be swallowed by Laravel's handler as generic ErrorExceptions.

Sequencing.

1. Due diligence spike (1–2 days): license, PHP support, test suite, a 30-line proof of concept against a real rule set.
2. Benchmark gate: measure query latency and memory against a representative rule base and against the current PHP implementation. If it is not within an acceptable multiple, stop here.
3. Boundary definition: agree the RuleEngine interface, result DTOs, error contract, and the rule-authoring/review process.
4. Container + config + facade: service provider, config, caching of compiled clauses, safety-limit defaults.
5. Safety and observability: step/time budgets, structured logging of query, duration, and solution count; metrics on failure rate and p99.
6. Test strategy: golden-file tests for query→bindings, fixture rule bases per module, and an explicit test for the timeout path.
7. Documented exit plan: what "rip it out" looks like and how long it would take.

Operational Impact

Maintenance.

• Assume you own it. Pin an exact version, forbid ^ ranges, and vendor or fork if upstream goes quiet. The code footprint is small enough that a fork is realistic, but only if someone on the team can read WAM-shaped code.
• The real maintenance burden is the rule base, not the library: .pl files need ownership, review, tests, and a changelog just like application code. Budget for that explicitly.

Support.

• No vendor, no SLA, no security-response process. Internal expertise is the only support channel.
• Prolog competency is a scarce skill in a typical Laravel team. Designate one or two engineers as owners and document rule-authoring conventions, supported built-ins, and debugging recipes.

Scaling.

• Inference is CPU-bound and single-threaded per resolution; horizontal scaling means more PHP workers, which is expensive per unit of reasoning work. Vertical scaling helps memory but not latency.
• Memory grows with choice points, not with knowledge-base size alone — pathological rule sets can exhaust a worker on modest input.
• Mitigations: memoize query results at the application layer (Laravel cache keyed on query + clause version), pre-compile clauses at deploy, cap knowledge-base size by design, and offload heavy inference to a dedicated queue with dedicated workers so a runaway query cannot starve web traffic.

Failure modes.

• Non-termination from left recursion or unbounded search → worker hangs until max_execution_time; symptom is a 504, not a stack trace.
• Memory exhaustion from deep backtracking → fatal error, uncatchable, worker recycled.
• Silent unsoundness — an unsupported built-in or a misunderstood cut yields false or wrong bindings with no signal. This is the most dangerous mode because it looks like a legitimate negative answer.
• Error opacity — Prolog error terms surfaced as generic exceptions, with poor mapping back to the offending clause.
• State leakage across requests under Octane if the engine or its clause store is held as a singleton.
• Mitigation: hard step/time budget in the wrapper, assertions on expected solution cardinality in tests, structured logging of every query with its clause-set hash, and alerting on timeout-rate rather than only on 5xx rate.

Ramp-up.

• A competent PHP developer needs roughly 1–2 weeks to become productive writing and debugging declarative rules, and considerably longer to debug the VM itself if something goes wrong below the API surface.
• Add onboarding materials: a supported-subset reference, worked examples from your own rule base, and a documented debugging workflow (trace output, minimal reproduction harness).
• The organizational cost is the paradigm shift: engineers must learn to specify rather than procedurally compute, and reviewers must be able to read that specification. Plan for this in the same way you would plan for adopting a new language in the stack.

TPM recommendation. At a 0.35 confidence score, this is a contained-experiment candidate, not a platform commitment. It is technically viable as an embedded, isolated reasoning module in a non-critical path behind a swappable interface, with hard resource limits and a queue-based execution model. It is not appropriate for latency-sensitive request paths, large knowledge bases, or anything where a hung worker or a silently wrong false is unacceptable. Gate adoption on the license check, a real benchmark against alternatives (SWI-Prolog sidecar, a PHP rules engine), and an explicit answer to "who maintains the rules, and who maintains the library when upstream stops."