New data serialization format. Curious what you think

12 Replies
pszemek
pszemek3mo ago
isn't that just yaml and toml combined?
kit
kitOP3mo ago
but it's actually more readable than yaml and simpler than toml i think it's a decent project idea, i thought the existing formats are too unusable so i made this now i think i should start describing the grammar in bnf
pszemek
pszemek3mo ago
what is bnf?
kit
kitOP3mo ago
backus-naur form and i want to write the first implementation in python maybe also a vim plugin used for formal syntax description
pszemek
pszemek3mo ago
maybe also do neovim, who uses vanilla vim anywayws
kit
kitOP2mo ago
vim plugins are compatible with neovim but neovim plugins aren't compatible with vim UPD: Implemented serialization algorithm in python if it can serialize/deserialize from/to python objects, it already means you can convert it to things like json/xml
Dumb Bird
Dumb Bird2mo ago
An alternative to the TOML example would be to add line breaks like you do with kdsf E.g.
[zoo]
animals = [
"Lion",
"Tiger",
"Penguin"
]
ticket_price = 30
some_array = [
[ 1, 2, 3 ],
[ 1, 2, [ 1, 2 ] ]
]

[zoo.some.really.complicated.nesting]
key = [
[ 1, 2, 3 ],
[ 1, 3 ],
[ 4, 4 ],
[ "hello", "world" ]
]
[zoo]
animals = [
"Lion",
"Tiger",
"Penguin"
]
ticket_price = 30
some_array = [
[ 1, 2, 3 ],
[ 1, 2, [ 1, 2 ] ]
]

[zoo.some.really.complicated.nesting]
key = [
[ 1, 2, 3 ],
[ 1, 3 ],
[ 4, 4 ],
[ "hello", "world" ]
]
The one thing I feel TOML has over kdsf is it's readability. I personally feel TOML is easier to approach for someone who doesn't program but needs to tamper with configs and such Whereas kdsf doesn't really have a design which makes it inherently intuitive (like omitting the equals sign) Akin to the language it's written in with the tab based coding instead of opening and closing braces, well I guess this is more of an obvious observation lol However I find the tab spacing style to make it a bit harder to follow Despite everything I have said I think kdsf does have it's pros and to be fair everything I said was subjective not fact. Keep me posted on your development
kit
kitOP2mo ago
my idea is that you can improve the readability by removing extra signs i think projects like this are inherently subjective and another key idea of that project is using only 3 data types
pszemek
pszemek2mo ago
I like minimalism but but for me it's hard to distinguish nested keys
kit
kitOP4w ago
yeah, it's de facto fixed in the implementation but i haven't updated the documentation i'm often away from my computer and the idea is kinda raw yet so the format will definitely be improved i will remove "simple strings" for consistency This should be better:
zoo:
animals:
"Lion"
"Tiger"
"Penguin"
key = "value"
dict:
key = "value"
key2 = "another value"
ticket_price = 30
some_array:
[1 2 3]
[1 2 [1 2]]
some.really.complicated.nesting.key:
[1 2 3]
[1 3]
[4 4]
["hello" "world"]
zoo:
animals:
"Lion"
"Tiger"
"Penguin"
key = "value"
dict:
key = "value"
key2 = "another value"
ticket_price = 30
some_array:
[1 2 3]
[1 2 [1 2]]
some.really.complicated.nesting.key:
[1 2 3]
[1 3]
[4 4]
["hello" "world"]
not the final version ofc, but that already looks decent but the dicts will probably look like this i will think about arrays
Dumb Bird
Dumb Bird4w ago
I much perfer this over what it was before
kit
kitOP3w ago
So this is how it should be used:
config:
this = "that"
plugins = ["plugin1", "plugin2"]
config:
this = "that"
plugins = ["plugin1", "plugin2"]
<statements> ::= <statement> | <statements> <statement>
<statement> ::= <pair> | <dict> | <array>
<statements> ::= <statement> | <statements> <statement>
<statement> ::= <pair> | <dict> | <array>
So arrays will be defined like this:
some_array = [
[1 2 3]
[1 2 [1 2]]
]
some_array = [
[1 2 3]
[1 2 [1 2]]
]
The language must support the usage of whitespaces, so i'll add this:
<spaces> ::= <space>*
<space> ::= " "
<spaces> ::= <space>*
<space> ::= " "

Did you find this page helpful?