I will try to make time to write up a comparison matrix of alternatives. But I'm slammed with work at the moment, so will be happy if someone beats me to it.
This :[a b c] could mean reduce [:a :b :c] (sometime in the future).
I'm not for required set-words in maps. Use contexts (objects), if that's more readable. I'm ok with both having words and set-words as keys in maps, and maybe they should be different entries into the map.
We don't have objects. This is Ren. :-) We also don't have the concept of reduce.
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.