I think, you have objects. Ok about reduce, as it is a format. But I see, set-words are planned, so set-blocks may not be ruled out because of some syntax.
"About #[a: 1 b: 2] , I see no point in having to write all the keys as set-words. "
I totally agree!... The main purpose of map! is that key may be any (almost?) datatype, not just word!
For Ren, then, we need to consider the "almost" part carefully. I agree that being able to use anything as a key value is powerful. What *can't* you use as a key? This is important because the Ren spec needs to be kept a simple as possible, while still allowing much more expressivity than JSON.
From the perspective of data exchange, should there be anything you can't use as a key in a map?
I think once we have the syntax settled, we can conceivably deviate between (base) Ren and full Rebol.
And, again we're talking Ren here, is this a good thing?
In Ren, it may be very useful to restrict potential keys slightly further, to ease interop with other languages.
For full Rebol, we could have slightly more relaxed restrictions.
In particular, I think that compound types as keys should be carefully considered for Ren.
Yes, Ren is separate, and not only good for interop, but also a helpful constraint to require keys to be set words.
Compound types: blocks, (parens?), maps.
Potentially helpful. It's a tough call, because we think in terms of Redbol, and want to exchange all data seamlessly.
Agreed on compound types.
Enormous power there, if you allow anything.
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.
And much more complex for interop, as you said.
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.