- How do I install hoa/compiler in a Laravel application?
- Install it with Composer as a plain dependency: composer require hoa/compiler. There is no service provider, facade or publishable config, so nothing needs registering in config/app.php. You then reference Hoa\Compiler classes from your own application service classes, ideally behind a narrow interface you own. Pin the exact version and commit the lockfile, since upstream is archived.
- Does hoa/compiler work with Laravel 10/11 and PHP 8.1, 8.2 or 8.3?
- There is no Laravel version constraint because the package is framework-agnostic and only requires PHP. The real question is PHP compatibility: the final release shipped in August 2017 and the whole Hoa dependency chain predates modern PHP, so PHP 8.x behavior is unverified and may need patches. Prove it with a time-boxed spike on your exact production PHP version before committing, and audit the full dependency tree rather than just the top-level package.
- Do I need a service provider or facade to use hoa/compiler in Laravel?
- No. hoa/compiler is a standalone parsing library with no Laravel integration whatsoever, so there is no provider, facade, config file or Artisan command to register. Treat it as an isolated parsing kernel behind an application-owned service such as GrammarParser::parse(string): Ast. Keep controllers, jobs and models importing only your interface, never Hoa classes directly.
- When should I use hoa/compiler instead of a hand-written parser or symfony/expression-language?
- Use it when you genuinely own a non-trivial grammar, such as a custom DSL, a configuration or markup format, or an expression or query language you need to validate structurally. For simple expression evaluation or existing PHP source analysis, symfony/expression-language or nikic/php-parser are far lower risk. For small, stable syntax, a hand-written recursive-descent parser is often cheaper than adopting an abandoned grammar engine. If CRUD, templating or request validation is the problem, this is the wrong tool.
- What is the difference between LL(k) and LR(1) parsing in Hoa\Compiler?
- LL(k) parsers read input left to right and choose productions by looking ahead at most k tokens, which keeps grammars readable but can hit conflicts when alternatives share prefixes. LR(1) parsers are bottom-up and handle a much broader class of grammars, including left-recursive rules, at the cost of harder-to-diagnose conflicts. Hoa\Compiler ships both, and you declare which one a grammar uses in its .pp file. Expect to spend real time on grammar design and conflict resolution, not on Laravel plumbing.
- How do I write a grammar with hoa/compiler's .pp grammar description language?
- Grammars are authored in Hoa's own .pp DSL, which declares tokens, rules and the parser type, then compiled at runtime by the library. Keep the .pp files in your repository under version control and load their paths from configuration rather than hard-coding them. Budget days, not hours, for the first working grammar: the cost is grammar-writing skill, not installation. Document the grammar's intent, since it becomes a piece of domain logic your team must own.
- How do I traverse the AST and use visitors in hoa/compiler?
- Parsing produces an AST that you walk with the library's visitor API, so you implement visitors for each pass such as validation, transformation or code generation. Keep ASTs from leaking into your application layer by mapping them into your own DTOs inside the parser service, so callers never depend on Hoa node classes. Reusable visitors are one of the library's better features and make interpreter or compiler backends straightforward to structure.
- How do I test a parser and grammar built with hoa/compiler?
- Test at two levels: table-driven tests that feed representative source strings through your GrammarParser interface and assert on the mapped DTO or AST dump, plus negative tests asserting that malformed input raises the expected exception with a useful position. Because your interface hides Hoa, the same test suite can run against an alternative implementation during a spike. Add a regression corpus of real-world inputs, since grammar edge cases are where this kind of code breaks.
- Is hoa/compiler abandoned, and what are the production risks?
- Yes. The package is archived with a final release in August 2017, no upstream maintainer, no security advisories and no CVE monitoring. Its Hoa dependencies such as hoa/core, hoa/stream, hoa/iterator and hoa/zformat are likewise unmaintained, so any vulnerability found is yours to remediate. Zero dependents in the ecosystem means no peer support and documentation that has largely rotted. That profile makes it load-bearing technical debt unless you explicitly accept ownership.
- Should I fork and vendor hoa/compiler, and what is the exit plan?
- If a spike proves it parses cleanly on your PHP versions and no maintained alternative covers the grammar, then yes: pin the exact version, commit the lockfile and vendor the source into a private fork so an upstream disappearance cannot break installs. Design the adoption so substitution stays cheap, defining your own interface and DTOs before writing any Hoa-specific code. Run a parallel spike against a maintained alternative and decide on evidence rather than momentum.