Skip to content

Project: DSL JSON like syntax for instantiating data types

SimonCockx edited this page Aug 18, 2022 · 5 revisions

Phase 3: add JSON-like syntax for instantiating data types

Problem

There is currently no way to explicitly instantiate a data type. As an example, suppose we want to describe an employee of a company.

type Employee:
  name string (1..1)
  salary number (1..1)
  isSeniorMember boolean (1..1)
  mentor Employee (0..1)

Currently, the only way to actually make an instance of this data type, is to define a function that returns an Employee. This is quite verbose, i.e.,

func CreateEmployee:
  inputs:
    name string (1..1)
    salary number (1..1)
    isSeniorMember boolean (1..1)
    mentor Employee (0..1)
  output:
    result Employee (1..1)
  set result->name: name
  set result->salary: salary
  set result->isSeniorMember: isSeniorMember
  set result->mentor: mentor

With this function, we can instantiate an Employee by calling CreateEmployee(...). We have to write such a function each time we want to actually instantiate some data type.

Solution

We intend to introduce an intuitive JSON-like syntax to instantiate a data type. For example, we could instantiate an Employee called Dwight Schrute who has a mentor called Michael Scott as follows.

Employee {
  name: "Dwight Schrute",
  salary: 4800.00,
  isSeniorMember: False,
  mentor: Employee {
    name: "Michael Scott",
    isSeniorMember: True,
    salary: 6300.00,
    mentor: empty
  }
}

Furthermore, these expressions will be validated automatically by our type system to guarantee correctness, i.e., no attributes were forgotten and each attribute is of the right type.

Note that properties may be written in any order (see the salary and isSeniorMember properties of Michael Scott).

Additional triple-dot syntax for assigning empty to all absent attributes

In many Rosetta models such as the CDM, it is common practice to have data types with many optional properties, e.g., with a cardinality constraint (0..1). In such cases, it is inconvenient to set most of them to empty explicitly. We'll therefore add a shorthand, ..., which stand for "assign empty to every other attribute". An example taken from the CDM:

type ProductIdentification:
  productQualifier productType (0..1)
  primaryAssetData AssetClassEnum (0..1)
  secondaryAssetData AssetClassEnum (0..*)
  externalProductType ExternalProductType (0..*)
  productIdentifier ProductIdentifier (0..*)

To instantiate this data type, we could then write

ProductIdentification {
  primaryAssetData: AssetClassEnum->Credit,
  ...
}

which would be equivalent with

ProductIdentification {
  primaryAssetData: AssetClassEnum->Credit,
  productQualifier: empty,
  secondaryAssetData: empty,
  externalProductType: empty,
  productIdentifier: empty
}

Note that if assigning empty to absent attributes would be done implicitly instead, it would be easy to accidentally forget to assign an attribute. The benefit of making this explicit with ... is that validation will be more thorough and might prevent additional mistakes.

Benefits

  • Constructor-like functions such as CreateEmployee can be removed from the CDM and other Rosetta models.
  • It becomes possible to instantiate empty data types such as the Zero type described above.
  • The triple-dot syntax improves validation, preventing mistakes from sneaking up in the CDM and other Rosetta models.