Custom parsers for the languages nobody else supports.

Off-the-shelf parsers exist for the languages enough people share. We license fifteen of them ourselves. A custom parser is what you need when your input is not one of those: a language your company invented, a dialect that drifted away from the standard twenty years ago, or a format that was never a language at all until somebody started writing programs in it.

When a custom parser is the right answer

Languages we have built parsers for

Not the catalog of products — those are on the licensing page. This is the other kind of work: one-off parsers built for one organization, for languages and formats most parser vendors have never been asked about.

Most custom parser work is done under an NDA, so the client is usually not nameable even when the language is. The organizations named above have agreed to be named or have said so themselves in a testimonial. If you want a reference in your own sector, ask and we will find out what we are allowed to tell you.

What you receive

A parser is not a deliverable on its own. What makes it usable six months later is everything around it, so that is what the engagement produces.

“The screen definitions I needed parsing had a few non modern constructs, such as special handling dependent on line column position and the delivered grammar handled that with aplomb. Delivery included a full suite of tests and extensive documentation including easy to understand comments.”

How we know when it is finished

Parser projects have a reputation for running without end, and the reason is almost always that nobody agreed what finished meant. We fix that before development starts, using the Chisel Method: you and we choose a validation set of real example files, and the parser is complete when two checks pass on that set.

• Check one: every example parses. The parser produces a tree for every file in the validation set. No exceptions carved out, no file quietly excluded because it was awkward.
• Check two: the tree is right for every construct. For each language construct in the set, the abstract syntax tree that comes out is inspected and validated. Parsing without a correct model is not much use.

Both checks are mechanical, so progress is a number rather than an opinion, and the goal is fixed before anyone has an incentive to reinterpret it. When both pass, the first version ships and maintenance begins — and if you add files to the validation set later, that is a new goal, negotiated as one.

Read the Chisel Method in full →

Every parser we build arrives in the same shape

This is the concrete reason to have us build it rather than someone else, and it has nothing to do with enthusiasm for our own methodology.

• One AST framework underneath everything. Every Strumenta parser is built on Starlasu and produces an abstract syntax tree in a shared shape. Tooling you write against one of our parsers — a visitor, a report, a diff, an exporter — is tooling that works against the next one.
• Your custom parser interoperates with the catalog. If your estate also contains COBOL, RPG, SAS or PL/SQL, the parser we build for your own language sits in the same pipeline as the engines we already sell, instead of being a separate island with its own conventions.
• Callable from five host languages. Java, Kotlin, Python, TypeScript and C#. The team that consumes the parser does not have to adopt the language it was written in.
• LionWeb support. The trees can be exchanged with tooling nobody at Strumenta wrote, through an open interoperability standard rather than through a format only we understand.
• Apache-2.0 foundations. Starlasu is public and permissively licensed, with implementations for Kotlin, Python, TypeScript and C#. There is no proprietary intermediate representation between you and your own syntax tree.

Error tolerance is part of the deliverable

A parser that stops at the first file it dislikes is unusable on a real estate, because a real estate always contains something odd. Ours return a partial tree plus positioned issues, so a batch over twenty thousand files finishes and then tells you where it struggled.

ERROR  unknown attribute in field definition
  SCREENS/ORDENT.scr:118:31
    FLD ORDTOT  COL 42  LEN 11  EDIT ZZ?,ZZ9.99-
                                          ^
  parsing continued: node kept, attribute marked unresolved

RUN    19,842 files · 19,839 clean · 3 with issues · 0 aborted

What we need from you, and what we will not promise

• Representative example files, early. Without them there is no validation set, and without a validation set we cannot define the goal, measure progress or quote a price. This is the one thing that genuinely blocks a start.
• No coverage number before we have read your code. Any parser vendor who gives you a percentage before seeing the corpus has made it up. We measure coverage against your files, and we report it as we go.
• Absence from the list above means we have not done it, not that we cannot. We have built parsers for languages that had no name outside one building. Bring us the input format and we will tell you what it would take.