Strumenta
Our approach focuses on clear, objective goals and measurable outcomes, transforming a complex process into a predictable and efficient task.
The main parser development challenges are
The Chisel Method
The Chisel Method is an approach to address the challenges in developing parsers for modern, complex programming languages by focusing on clear, objective goals and measurable outcomes.
This process supports building parsers efficiently and consistently according to the StarLasu approach to Language Engineering development at Strumenta.
The basic structure of the process is the following:
Define goals
We define a clear goal, which is shared by the Client and the Language Engineering Team. This goal is objective, and it is not subject to interpretation
Frictionless Development
At each step, the Language Engineering Team should clearly understand where we are and what should be done next. Tool support should facilitate each single step, removing friction due to repetitive tasks
Frictionless Adoption
We ensure frictionless adoption by providing all support needed to facilitate the adoption of the parser inside a Language Engineering Pipeline
Learn more about the Chisel Method
Having a clear and shared goal is fundamental to avoiding disagreements.
The Chisel Method is based on having a very clear and measurable goal. The goal of the parser is to have two validation checks pass on a validation set of example files selected before the start of development.
The two checks are:
1. Validate the AST built for each construct. This guarantees our ASTs are correct
2. Being able to parse all the examples. This guarantees we can build an AST for our examples
Once those checks are passed the parser can be deemed complete. The first version can be delivered and the maintenance phase can begin. During the maintenance phase, more files can be added to the validation set, and therefore a new goal can be defined, in a sense.
Why not use the specifications for setting up the goal?
One way to define the goal of the parser could be “let’s support everything that is written in the specification”.
While this may seem a natural option there are a few problems with it:
1. Not all languages for which we need to write a parser have written specifications.
2. It is difficult to measure progress with respect to specifications. One could say, I have covered 3 out of 20 chapters of the specifications so I am at 15%, however that would not be a proper way to measure progress. Besides, it is very difficult to verify that specifications are “covered”. It is a manual process and cannot be automated.
3. Specifications are subject to interpretation. The Language Engineering team and the Client may disagree on the meaning of some parts of the specifications
The main ideas behind the Frictionless Development are that:
1. The Language Engineering team should always know what needs to be done next;
2. The tooling should facilitate every single step, removing all friction. If in a tool I can see an issue reported, I should be able to navigate immediately to the problematic point in the code. If I want to run the parser and it needs to be rebuilt, the rebuilt of the parser should be started automatically.
This workflow consists of two phases:
1. The Parse Phase: during this phase, we aim to have the first check pass, so as to be able to parse all the examples
2. The AST Refinement Phase: during this phase, we inspect and improve the ASTs we produce.
During the whole process, we can measure progress as a percentage of completion of the whole process. This is useful for internal planning and for communication with the Client.
A parser is a component that is always integrated in Language Engineering Pipelines. Per se a parser is useless, it produces value only when integrated. So facilitating integration is key.
We do that through three means:
1. Providing good connectivity: this is done by providing good APIs (through the StarLasu libraries) for native integration, by using the The StarLasu Adapter Mechanism for cross-language integration, and through LionWeb in other cases.
2. Providing documentation: we generate the documentation using our internal documentation tool.
3. Making this method teachable: this guarantees that on our side we will have a team able to maintain the parser and potentially we can train the Client’s team to take over maintenance. This reduces the risk for the Client.
Why adopting the Chisel Method is an advantage?
Clear Objectives
- Clear Goal Definition: This definition focuses on setting concrete, measurable goals, such as the ability to parse a pre-selected set of example files and validate the correctness of the generated ASTs.
- Objective Progress Measurement: Progress is calibrated by tangible outcomes like the number of successfully parsed files and validated ASTs, providing a clear and objective measure of development progress.
- Efficient Development Cycle: Chisel ensures a streamlined and efficient development process by avoiding subjective specifications and focusing on concrete examples.
Robust connectivity
- StarLasu Libraries: Provides user-friendly APIs for seamless integration.
- Cross-Language Integration: Supports multiple languages (Java, Kotlin, JavaScript, Python, C#) and allows interaction between components written in different languages.
- Language Engineering Pipeline: Structured approach to language processing and translation.
Comprehensive Documentation
- Automated Documentation Tool: Generates clear, up-to-date documentation to aid in integration and usage.
- Know your code: supporting statistics and analysis to understand your code in a way you have never understood before.
Teachable Methodology
- Structured Learning Path: Breaks down the development process into manageable stages.
- Automation of Tedious Tasks: Reduces human error and simplifies learning.
- Client Training: Long period support and clients training for custom parsers.
Chisel is a method and a transformative approach to parsers development, ensuring efficiency, adaptability, and sustainability.
How I can learn more?
Do you have questions?
Let’s have a chat! Schedule an informal meeting with us, and we will answer all your questions about our method, explain our solution in detail, and be available to answer all your questions.
Watch the talk about “The Chisel Method”
Frequently Asked Questions
If I need more information?
We have written an article about the Chisel Method “Chisel: an open source method for parser”. If you need more information about the Chisel Method for building parser or you are interested in buying a parser from us, you can schedule a meeting we will be more than happy to answer your question
Anything else you could help me with?
We are specialists in Language Engineering, and we can offer all these supporting services to ensure you reach your goals. Typically our clients buy a transpiler to use as part of larger systems. Sometimes they have all the internal skills they need to integrate. Still, often they ask us for training courses, support with the architectural design, or the implementation of the entire system for you.
Where can I find references and testimonials of other clients?
You can have a look at our session “Testimonials” to read some customers experience and opinion. You can also find some interviews in the section “Articles“: Interview with Rob Wunderlich or Interview with Campbell Pride.