xDLs

xDLs is the concept of a definition language file, targeted at one specific domain.

These include

• DDL - Data Definition Language
• IDL - Interface Definition Language
• EDL - Editor Definition Language

Background

During the initial discussions there was a suggestion of creating a companion EDL (editor definition language) aimed at UI editors of the data defined on DDLs. The initial idea was that of a definition complementary to the primary one in the DDLs, that focused on the usage specific of editors, while freeing the primary DDL from being cluttered with editor info. At the same time, in different discussions, became apparent the need for an IDL that could define not just the data layout, but also methods and interfaces provided by different systems or tools.

Motivation

One of the goals for the primary DDL is to be simple. Simple to write, simple to parse, and simple to extract meaningful data from a file. This enters in conflict with the evident need for more specialized uses and features for the DDL, and storing all kinds of specialized DDLs in a single file.

Proposal

One possible solution to this issue is to add support for a xDL file. This file would contain any type of specialized xDL that conforms to this xDL meta-specification. To make this type of file easy to be supported on both this project parsers, and any parser that might end up supporting any of these xDL formats, the schema should be friendly and help the parser navigate blocks that don’t belong to that specific xDL. This can be achieved by having a similar syntax structure on any xDL adhering to this meta-spec.

Possible syntax structure

keyword id (token0, token1, …, tokenN) { (keyword_contents) }

Examples

def interface Foo
{
    Bar(Data data) -> CompiledData
}

def struct Bar
{
    foo: int32,
    bar: float16
}

Pros

Shared parsing infrastructure might make it easier to develop and integrate new xDLs into existing pipelines

Cons

Possibility to integrate custom xDLs might fragment usage and create issues in sharing files across projects, or updating and adopting new xDLs into the community xDL library.