New data serialization format?

Share your Projects
,
1

Ditch (printable @list ::lists) and forget about ([json V] of @list). I have devised a data serialization format oriented for Snap!. Thoughts on this?

https://snap.berkeley.edu/snap/snap.html#present:Username=mobility212&ProjectName=Snap!%20Data%20Serialization&editMode&noRun

Here is an example snippet:

{number: 384, text: '\\"_"/', Boolean: true, list: [1024, Gremlin, false], color: rgba(145, 26, 68, 255), script: ((move 10 #1) (say (get #1))), sprite: spr(Sprite), stage: stage()}

I have only developed the "stringify" mechanism, not yet the "parse" mechanism. I might also get around to costume and sound support (I took maybe every single type including "nothing" and "selector" into consideration, but these two), as well as handling circular lists.

I developed that because I really loathe JSON for being so overly stringent despite being a popular choice for data serialization. Not only you need to quote your keys, but you also cannot use ' (apostrophes) as a substitution for " (quotation marks). JSON's necessity for quotation marks incentivized me to be lenient with omitting quotation marks (unless there is potentially conflicting syntax).

2

My immediate reaction is that the benefits of being able to edit Snap! projects in any old third-party JSON (or XML) editor outweigh any minor virtues to your syntax. You’d do better to get them to change the JSON rules!

3

What if the sprite’s deleted, or if the object’s a clone?

4

Then maybe you’ll like json5

5

Offers reasonable leniency, though I want to design a format oriented just for Snap!.

6

Sprites would be looked up by name. If there is no sprite with such name, ...you get the idea.

I could number clones that are unnamed, and assign it to the parent sprite.

By the way, this is a human-readable data serialization format, not a full-fledged raw data format that holds all the data for a sprite within one object.

8

What should we name this language?

9

Here’s what comes to mind:
ROSS format: “Readability Oriented Snap Serialization format”

or, just for fun:
JINJOTS: “JINJOTS Is Not JSON Oriented Towards Snap”

More on JINJOTS

We can expand further:

“JINJOTS Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap”

“JINJOTS Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap”

“JINJOTS Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap”

“JINJOTS Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap”

“JINJOTS Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap”

“JINJOTS Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap”

“JINJOTS Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap”

“JINJOTS Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap”

“JINJOTS Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap Is Not JSON Oriented Towards Snap”

You’re still reading?

10

TISNAGN… (TISNAGN is not a good name..) (T = That in the first-first version inside billions of TISNAGNs)
Gives WINE (Wine is not a emulator) vibes

I think the ROSS name is better, its shorter. JIN-JOTS? Is that how you’ll pronounce it?
Or maybe remove the “JIN” and keep “JOTS”, that might work also

11

???

It’s way too dramatic. JSON is fully readable but slightly redundant at writing.
As for the brevity, there is a YAML

untitled script pic - 2026-02-25T200425.285
untitled script pic - 2026-02-25T200425.285728×252 25.6 KB

YAML

---
f1: field1
f2: [A, B]
f3: true

Serialization for the trivial scalar values is … hmm, trivial.
The hardest part is serializing complex structures. If you already understand the script format, standard objects may be referenced consistently by an expression
untitled script pic - 2026-02-25T205142.628 => (object mySprite)
untitled script pic - 2026-02-25T204439.519 => (colorFrom “rgba(145,26,68,1)”)
untitled script pic - 2026-02-25T204804.679 => (my [stage])

Also, there should be a simple, fast type hint to call the appropriate deserialization code.

12

Ah yes.

13

I like this one too.

14

I do not expect my data serialization format to make an appearance in professional use. I just started this project for fun, as well as to deal with my hatred for JSON and its ubiquitousness, which I find its syntax strictness inane.

I read a JSON file that has not been prettified to be readable, so everything is on one line. All these quotes are wasting space.

What do you mean by "slightly"? I cannot stand it... all the quoting needed. I do not know anyone who wants mandatory quoted keys in a language with barely any special syntax, just four literal types and two object types.

I prefer to have my own format. The only part that I am borrowing from is scripts, which I am borrowing from Snap!'s Lisp.