AltME: Ren - Data Exchange Format

Messages

Gregg
I think multiline strings offer so much value that we need them. Any strong arguments against?
On encoding, I'm good with requiring UTF8. Any arguments against?
Rebolek
I agree with both multiline strings and UTF8.

Gabriele
one note about multiline (not just strings, in general): a lot of things assume JSON to always be able t o fit in a single line. Eg. use line terminator as delimiter between JSON objects. (Eg. IPC in node.js is line terminated JSON)
Gregg
Interesting. There is certainly something to be said for mashing things into one line in certain contexts. I have a SINGLE-LINE-MOLD func I use for logging, for example, and having tools that could operate in a mix of line-oriented nix fashion with each line being structured, is a possibility too.
DocKimbel
Gregg, did you miss MOLD/FLAT? :-)
Gregg
It doesn't remove line breaks.
Ah, Red does. So my func is obsolete. :-)
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.

Last message posted 181 weeks ago.