AltME: Ren - Data Exchange Format

Messages

Maarten
Hocon is a pretty nice format. Basically, a firendlier superset of JSON https://github.com/typesafehub/config/blob/master/HOCON.md
Gregg
Interesting. I hadn't seen that. It's not just a format though, it defines a lot of behavior as well. I think we may offer some guidelines for Ren library behaviors, but I don't want to head down the path Hocon has. And some things just seem like a bad idea. e.g.:
// this is an array with one element, the string "1 2 3 4"
[ 1 2 3 4 ]
// this is an array of four integers
[ 1
  2
  3
  4 ]
Gregg
It did remind me of something on a Units type format. They talk about n^2 vs n^10 byte values and, e.g. the kilo vs kibi prefix or kB vs Ki. For byte units, my thought was to do something like binary! where you would do KB2 or KB10.
Reichart
Wonky case sensitivity https://github.com/typesafehub/config/blob/master/HOCON.md#size-in-bytes-format
(not that there is a better solution per se)
I wish there was a page with side by side JSON vs this for example.

Gregg
Map comments (also posted in Gitter)
I'm considering both [] and () as list and map brackets for Ren. What I haven't considered is the newer concept of allowing any value as a key. If Ren supports that, does it even need a separate map type? If Ren requires set-word keys, Red can directly support Ren maps, but not the other way around. Red maps would have to become Ren lists. If we do that, we lose the ability to distinguish them from parens when exchanged via Ren.
The idea of allowing () for lists is that it makes Ren more Redbol compatible, as well as flexible for those not used to square brackets. We may decide that more constraints are better, at least to begin with.
There is nothing that says Ren has to require pairs of values either, though there is certainly merit in that. We could just as easily say that a leading # before a list is just a hint.
e.g., if there is no map hint, the loader should never try to coerce the result to a map, if there is a hint, the loader decides what type to coerce to based on contents. If there is no outer list, as in a streaming scenario, there is implicitly no hint.
This came from seeing https://github.com/red/red/wiki/Map!-datatype that defines literal map! syntax in Red.
DocKimbel
Remember that map! in Red is just a specialized version of hash!.
And hash! is as flexible as block! is.
Gregg
Understood. The question is not what Red can do, but what Ren should support.
DocKimbel
Well, if you move too far from Redbol syntax, I'm not sure where you want to go with Ren.
Gregg
I would love for Ren to just LOAD in all Redbol langs. But they're not all equal either.
DocKimbel
At the beginning, Ren was about promoting the Rebol data format, so that non-Rebol users could enjoy a more human-readable format. But I'm not sure what are the current goals now?
Gregg
And it needs to balance against a JSON comparison.
My goal is the same. Basically REBOL, perhaps eliminating things to appear simpler, and the need to add a literal map syntax.
DocKimbel
If you don't have the need to support construction syntax in Ren, then it frees the #[...] form.
Or you can use #(...) as in Red now (and in Rebol3 in the future).
Gregg
Right, hence my questions above. Does Ren not care what is in the block structs? If it doesn't enforce name-value pairs in #[] or #(), then old construction syntax and Red maps are both valid.

Last message posted 176 weeks ago.