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 ;[...].
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.
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].
And for something completely different! To break the left-brainedness of this whole thing, here is a (as far as I can tell unrelated) cool song that I just remembered (because the mind works in mysterious ways): https://www.youtube.com/watch?v=Ir9jfA6XgCg