AltME: Ren - Data Exchange Format

Messages

Gregg
Though mine, IIRC, replaces line breaks with their escaped counterparts.
Ah, Red does that too, on ML strings. You win. :-)
And thank you. :-)
DocKimbel
;-)

Gregg
Back to time!
Gregg
# Use cases
- standalone time (point in time)
- standalone time (duration)
- part of date-time (time of day)
- timezone (offset from UTC)
#Proposed rules
    time
        hours-minutes opt seconds
    hours-minutes
        opt sign  uint : uint
    seconds
        : uint  opt frac
My argument for this is that it keeps the rules simple, and is flexible but still constrained.
Votes? And if you vote No/-1, a short reason please.
DocKimbel
-1 because I think that date! and time! values should be normalized in a data exchange format. Though, specifying such rules would make the spec significantly more complex, but not doing it would just shift the burden onto the implementers, which might result in different interpretations. For the duration use-case, I am for using a different format than time!, maybe resulting in a new datatype.
(I am taking the perspective of people implementing REN in non-Rebol languages)
Gregg
How does the above proposal make it harder for non-Redbol languages?

DocKimbel
Answered in "Ren - Time & Duration" group.
Gregg
Anything specific in YAML? I do note it, and other formats evaluated and why Ren isn't them.
DocKimbel
YAML format is getting traction among open source projects, it is nicer and richer than JSON. It provides "heredoc" features for embedding other formats (like XML or JSON). It's a very good human-readable format. OTOH, the specification itself is rather long and complex, but that is not a show-stopper for YAML adoption among many languages. I think we have to learn from it.
Maybe providing a C-level library for Ren would be a good way to simplify the integration with non-Rebol languages.
Gregg
I looked at YAML in depth many years ago, and even started a parser for it at one point, thinking it looked OK on the surface, but I quickly gave up on it. Aside from a couple JS tools using it for config/proj files, I didn't know it was gaining wider traction. What looks simple and readable really has complex rules that can leak through to users. I'm happy to have someone point out specific things we can learn from it though.
I mentioned a C Ren lib as an important piece to aid adoption in another group, so I very much agree.

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.

Last message posted 408 weeks ago.