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.
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.
"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.
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 :-)
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.
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)
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.
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)?
For data exchanges purposes, I think you can stick to a more restricted format for time! than the one allowed by Rebol at runtime, like HH:MM:SS.s and only positive values.
That was my original thought as well, and what Ren specs today, with negative hours allowed. That implies that the entire time is negative, which I use today. Consider time ranges. e.g., a target time +/- N minutes. I think we can live without mixed sign time values. Mixed sign values aren't intuitive, though their results make sense if you think about them.
On the number of digits, if we limit it to HH:MM:SS.s, do we also say the values have to be valid sexagecimal (00-59)? It complicates the grammar just a bit, and does it provide value over allowing any integer value in a segment?