AltME: Ren - Data Exchange Format

Messages

Andreas
And enormous potential for problems as well, because you then need to carefully define a equivalence story as well.
But I think for primitive types, most if not all of them should be allowed as keys.
Gregg
Right.
And much more complex for interop, as you said.
Andreas
I also think that a relaxed restrictions on keys may actually be something of a "selling point" for Ren.
JSON decidedly represents "objects", which entails strong restrictions. But in practice, most implementations don't really exchange "objects" through JSON, but rather a generic associative datastructure (maps, hashtables, dictionaries). Also, because JS objects don't really fit that closely to objects in other languages.
So if we start with maps instead of objects in the first place, with relaxed restrictions on keys, we have a much closer fit to reality than JSON does.
Gregg
Agreed.
Lua comes to mind, because anything can be a key in a table, correct?
And the complexity of allowing them is offset by the consistency.

Oldes
"Ren spec needs to be kept a simple as possible, while still allowing much more expressivity than JSON."
So you should first of all not think about map! datatype, and use block! (without set-words) or object! (if you want set-words as keys), but map! with just set-word! key is a nonsense.
Oldes
One of real life examples why to use map! (or hash!) instead of block! or object! would be unicode collation http://unicode.org/Public/UCA/6.3.0/allkeys.txt - I don't see any usage there for set-word! keys. But I probably don't understand the main purpose of REN :-)
Rebolek
Actually, it doesn't matter that much, if it is map! or object! -- the thing is not to write "make map! [...]" or "make object! []" in REN (or use construction syntax). It should be simple and usable by people who do not know anything about Rebol.
Oldes
I just wanted to tell that map! with just set-word keys is not a map! and you should not call it this way as it confusing. Actually I joined this just because I saw map! notation syntax discussion... now I see that it's REN group.
(set-word keys in notation - word! keys should be used in my sentectes above)
Gregg
Here are the current Ren references:
    https://github.com/humanistic/REN
    http://pointillistic.com/ren/
The two are not coordinated, and we should bring things together. Not a big issue right now, but it will help avoid confusion.

Gregg

Gregg
Literals for inf and NaN?

DocKimbel
Gregg
Ah, thanks! I'm not sure of how useful they'll be, but if we're talking about passing messages and results around, they could be important in some fields.

Gregg
Should time! values be restricted in number of digits and signs? REBOL allows integer values for hours and minutes, which is converts to sexagecimal values. Minutes can be negative, as can hours of course, but second can't. Negative minutes are subtracted from hours. Also, if you only specify two segments, they are HH:MM if both ints, but if the second is a decimal, it becomes MM.SS.s. And scientific notation is not supported for seconds, nor are decimals for hours or minutes.
The main thing for Ren is that values need to be unambiguous. But what other limitations should be imposed? And should similar rules apply to other segmented numbers (tuple and pair/point)?

Last message posted 176 weeks ago.