djedr/ron-to-djevko.md

## ron-to-djevko.md

      
    Raw
  

              ron-to-djevko.md
            
          
    This is as part of a comment on a post on Hacker News "Ron: Rusty Object Notation".
The following examples from https://github.com/ron-rs/ron
GameConfig( // optional struct name
    window_size: (800, 600),
    window_title: "PAC-MAN",
    fullscreen: false,
    
    mouse_sensitivity: 1.4,
    key_bindings: {
        "up": Up,
        "down": Down,
        "left": Left,
        "right": Right,
        
        // Uncomment to enable WASD controls
        /*
        "W": Up,
        "A": Down,
        "S": Left,
        "D": Right,
        */
    },
    
    difficulty_options: (
        start_difficulty: Easy,
        adaptive: false,
    ),
)

Scene( // class name is optional
    materials: { // this is a map
        "metal": (
            reflectivity: 1.0,
        ),
        "plastic": (
            reflectivity: 0.5,
        ),
    },
    entities: [ // this is an array
        (
            name: "hero",
            material: "metal",
        ),
        (
            name: "monster",
            material: "plastic",
        ),
    ],
)
can be translated into a Jevko-based format as:

Compared to RON, the Jevko-based format is much simpler and more minimal.
It does not use any colons, quotemarks, commas, or slashes for comments.
It uses only one kind of brackets: the square brackets.
Line comments are just text at the end of a line, without any introductory sigils.
Primitive types look like [value].
Arrays/sequences look like [[v 1] [v 2] [v 3]] (spaces inbetween the values optional).
Maps/dictionaries look like [k 1[v 1] k 2[v 2] k 3[v 3]] (space around keys is not part of them).
There is no distinction between structs and maps or between tuples and arrays. Note: this does not preclude enforcning that distinction when decoding (see e.g. this comment).
Numbers look like numbers, e.g. [123].
There are a few keywords: true, false, seq (empty sequence), map (empty map), nil (null -- the aim is to match JSON's data model).
A line that does not look like a keyword or a number is a string.
Multiline comments look like ;[...].
Additional features (not shown here)

Multiline comments shown here are in fact an instance of a more general mechanism: disabled entries. Any entry in a map or in a sequence can be preceded by ; to exclude it from the collection ("comment out").
Multilne strings look like [`lines...`] (surrounded in backticks).
To make a string that happens to look like a keyword or a number, surround it in backticks, e.g. [`true`].
Multiline strings can be turned into Heredocs by surrounding the backticks with an identifier, e.g. [id`lines...`id].
Heredocs can be used to e.g. embed documents in other formats. It is possible to precede the heredoc identifier with a document (parser) identifier, so that it can be deserialized with that parser into a proper data structure, instead of a string, e.g. [pid\id`document...`id].
NOTE: multiline strings and heredocs are features specific to a variant of Jevko I've been working on recently, codenamed Djevko, not plain Jevko, as specified here.
Whitespace

This format is not indentation-sensitive.
Whitespace around keys and values is optional.
Whitespace inside keys is allowed.
To add leading or trailing whitespace to keys (generally not desirable), surround them with backticks, e.g. ` key ` [value].