GSoC 2024: Alias Support: Enhancing Model Flexibility in Concerto

Author: Jaskeerat Saluja, a contributor to Google Summer of Code 2024
GSoC project link

1. Project Overview
   1. Objective
   2. Value
   3. Coding Methodology
2. Coding Journey
   1. Extending parser(concerto-cto)
   2. Updating runtime(concerto-core)
   3. Updating introspector, analyser
   4. Extending Codegen
3. What Lies ahead
4. Learnings and Experience
5. PRs & Issues

Type aliasing refers to creating a local name for an existing type , giving tool to deal with name collisions. The objective of this project is to enable aliasing for imported types in concerto language and hence enhance its flexibility. The new implementation should be backwards compatible.

Below is an example of how we want to import two types with the same name: invoice from finance and invoice from procurement. When we use the type, we have ambiguity in resolving the kind.

We need more flexibility in our language to fix the above issue by allowing alias types to be used with a different name.

We can fix above ambiguity as follows

In the above, we have aliased Invoice to FinanceInvoice and ProcurementInvoice, respectively.

Throughout the program, I used a whiteboard to flesh out the implementations. I used Obsidian software to make notes, create flowcharts and diagrams, record meeting notes and design canvas. I had weekly sync with my project mentors; apart from this, I could connect to my mentors if there was an urgent requirement. I solicited inputs from the community via Discord , Github Issues and weekly tech working group meetings.

The first step we did was to extend the concerto-metamodel by introducing the concept of AliasedImport. Further, we extended the definition of ImportTypes by adding an optional array for AliasedImport.

The above changes are backwards compatible as we introduced an optional field AliasedType in the concept ImportTypes.

The pull request for the above change is merged.

After concerto-metamodel has been extended to allow AliasedImport in the ImportTypes concept, the next step was to decide on a syntax for the aliased imports and then define the grammar rules.

After several discussions in the Technology working group, the maintainers at Accord Project decided to agree with the Typescript style syntax for the aliased imports concerto.

• ns: Represents the namespace from which types are imported.
• type: The original type name is being aliased.
• t: Alias assigned to the imported type.
• as: Keyword used locally within the import statement for aliasing

 Aliased imports can coexist with non-aliased imports within the same statement.   Example:

The Parser for concerto resides in concerto-cto written in PEGJS. I had used the online peggy compiler for experimenting and coming up with the grammar rules for the above syntax.

While coming up with the rules we considered the following edge cases.

The pull-request for above changes is merged.

In the concerto environment, we have concerto-cto, a parser that takes in concerto code and outputs an AST(Abstract Syntax Tree). This AST is then verified for semantic correctness by concerto-core, a runtime analysis module. These two components play a significant role in ensuring the semantic correctness of the code.

While extending the concerto-core module, the major task was ensuring that aliased types were resolved correctly to their fully qualified names, using data structures to store the aliased types map.

By default, aliasing is disabled in concerto-core. To enable aliasing, we must set the field  importAliasing: true while initiating the model manager.

• A model file object manages each concerto file.

•  The modelFile object includes a getType function.

•  The getType function resolves and returns the fully qualified type name.

•  Changes were made to the getType function to handle aliased types.

•  Due to the internal type resolution, modifications were only needed in the model file class.

The PR for the above changes is merged into the main.

Concerto supports exporting concerto models into various formats as listed here. The main task in extending codegen was to ensure that aliased types were mapped correctly in the exported format.

I started with support for C# and Java, currently in review and should be merged soon. The changes in each repo are minimal and can be replicated easily for the other format.

Concerto analysis is a tool that allows users to compare two Concerto models to detect new, updated, and removed model elements. The analysis results can then be used to update the versions of namespaces, adhering to semantic versioning best practices.

The Tech-working group decided to label the aliasing changes as PATCH changes. The feature is handled in PR and discussion related in Issue.

Below is an example output for above changes.

Executing below

I have learned several things in these 12 weeks. This first was how to plan the whole project by breaking it into several small steps, assigning priority, and setting expectations beforehand. Doing this gave me a lot of clarity in planning my coding period. Ertugrul helped me plan the project timeline, even though I had planned it while preparing for the GSOC proposal earlier this year.

I learned many small day-to-day development hacks and methodologies from my mentors.

Implementing my compiler design skills in this project was a significant learning experience. I am truly grateful for this opportunity, as it has significantly enhanced my practical knowledge and skills.

Participating in GSOC 2024 with AccordProject was an amazing experience. The highlight of the program for me was the Technology Working Group meetings, where I gained the most knowledge and insights. I am truly grateful to my mentors, Ertugrul and Muhammed, for their consistent guidance and unwavering support throughout the entire program. I am also thankful to Matt, Diana, and Dan Selman for their invaluable feedback during the Technology Working Group meetings.

I’ll continue to contribute to the Accord Project and will try to add more developers to the community.