There are 14 languages ​​for storing data… Or how IEML came about

background

Somehow work was carried out on one engine to create a GUI, some kind of Qt. It was distinguished by the fact that the end user could customize this interface using the config to the smallest detail.

Initially, YAML was taken as such a config, it sounded reasonable, a simple format for the average person, if not a grandmother, then at least a slightly advanced gamer can handle it.

During the integration process, it turned out that we lacked this format, and some of its other disadvantages began to appear. As a result, it was decided to create its own format.

Start

The format is called IEML. It is partly inspired by YAML, so you should expect it to be mentioned a lot in the article.

A number of requirements were made to him:

  • Keep the visual simplicity of YAML to the maximum

  • Be strict (do not allow deviations from syntax)

  • Be explicit (have no syntactically overlapping data types)

  • Be uniform

  • Be minimally redundant

  • Have functionality to improve readability and avoid copying

Format

In the name of simplicity, it was decided to make the format dependent on indentation. Some will say that such a notation is error-prone, but it’s not a programming language that has syntactic error protection.

Only tabulation was chosen as indentation, why exactly it can be read here, also from the same article you can understand why the choice fell towards the complete rejection of spaces.

Most special characters include spaces, they are required, extra spaces are not skipped, in most cases they will be considered as raw data or an error.

Blank lines containing tabs, spaces, and comments are allowed between elements.

Almost all scalar data types from YAML have been retained and 1 new one has been added:

Each of these types has its own characteristics and deviations from their traditional spelling.

All scalar types can be transferred to the next line, subject to indentation, and all non-scalar types can be written into one if they contain only one element.

In addition to the features and non-scalar YAML types, two new ones have emerged:

  • Lists

  • Dictionaries

  • Anchors

  • Tags

  • Files

Comments

In order not to lose the ability to add your own type for commands or file paths (We will discuss this later), it was decided to denote comments with #but again, in order not to lose the opportunity to add a type of hex-color, the obligatory after that should go or ! (For shebang capability).

As a result, the comments look like this:

#!Это комментарий
# Это комментарий
#А это уже ошибка

Boolean values

Despite the almost unambiguous prevalence true\falsethe choice fell on yes\no.

It’s easier on the layman, it’s more accurate in most contexts, it’s shorter.

In addition, the format obliges the parser to allow these values ​​to be read as raw data, so the Norway Problem is completely solved.

Numbers

Any number must contain at least one digit in the integer part:

1 # 1 
1.0 # 1.0
1. # 1.0
.1 # Ошибка

Any number containing . in the mantissa is considered a fraction. Yes, numbers support exponential notation, which is written with a letter e .

In addition, the standard allows you to write numbers in any number system from 1 to 36. To do this, use the symbol ‘ before which the system is written (in decimal notation), and after – the number. For example:

2'101

It is the number 101 in binary.

Strings

The format allows you to write a string in 3 different ways.

  • Classic using " and with shielding support

  • Not shielded using >> and its shorthand in one line with >

Both methods support wrapping to the next line, but require respect for the indentation level.

Examples:

"Hello Wolrd!
  " # "Hello World!\n "
>> # Здесь можно писать комментарии.
Hello World! # А вот это уже не комментарий, что бы строка кончилась должен быть понижен уровень отступа.

Null

Recorded with nulleverything is normal here.

raw data

Written if the data could not be parsed like some other part of the language, while a number of conditions must still be met, such as not using most of the language’s special characters. Always a one-liner.

It is needed to enter new data types, for example, hex-colors, which were already mentioned earlier:

#FFFF00

Lists

Require before each element - . For example:

- null
- -10

In addition, there is a short entry using [] and with elements through , but the list of nested types is limited.

[null, -10]

Dictionaries

The key is always a string, if any other dictionary is required, a list is used.

Key and value are separated : .

first: null
second: -1

Tags

A tag is a small line of additional useful information that does not take up much space.

The tag always starts with = and ends : is written before the value to which the tag is assigned.

- = tag: null
- 
	first: = other tag: -15

Anchors

YAML has not fully developed this concept.

They are also marked with & to take and * to get, but unlike YAML, they can be in any order and this shading in one file is not allowed.

- *anchor # Здесь тоже находится "Hello"
- &anchor > Hello

And that is not all.

Files

The format provides a mechanism for including files. This allows you to split large files into smaller ones, making reading easier.

But more importantly, these files are integrated with anchors, each file creates a scope for anchors, all anchors from parent files are visible in child files, but not vice versa.

And more importantly, it allows you to templatize data, including files multiple times with different anchors. Therefore, when including files, there is a special syntax for passing anchors exclusively inside the file.

To include a file, write < , then the path to the file, but without the extension, file extensions are fixed, so there is no need to specify them. If you need to pass anchors, then immediately after including the file at the appropriate indentation level, a dictionary is written in which the key names are the names of the anchors, and the values ​​are the contents of the anchors.

Normal file include:

< path/file-name

Including a file with passing anchors:

< path/file-name
first-anchor: null
second-anchor: -15

Comparison

IEML

YAML

JSON5

TOML

Numbers in various calculus systems

+

+

+

Numbers in any number systems

+

Null

+

+

Unescaped strings

+

+

Tags

+

?

Anchors

+

+

Files

+

Full graph document structure

+

Uniformity

+

+

Explicitness

+

+

+

High operating speed

+

lightness

+

Type Date and time

+

+

Implementations

At the moment there is only one implementation on C++, but an implementation for Rust is already being written. In the future, it is planned to add an implementation for PHP. But the rest of the languages ​​​​are only hope for enthusiasts from the community.

Outcome

Perhaps the format was not ideal, but in my personal opinion – good, applicable, but not everywhere. I will be glad to criticism in the comments.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *