I can't say what a big deal it is, but the idea behind #[a: 1 b: 2] for maps was for two reasons:
1) For direct comparison to JSON. Cleaner and shorter wins there. 2) For use in config files and such. Avoiding datatype keywords for humans seems like a good idea.
:[...] came up as well, as did ::[...]. Those are nice from the standpoint of the : having meaning, but the single leading colon isn't as visible.
what about asterisk? Does it imply multiplication too much? *[a: 1 b: 2]
@[ ... ] for map! syntax is still on the table.
A map as a construction is #[map! ...] (as Gabriele point out, I think)
There is a distinction between the two. Better not let #[ mean more than one thing, and it is a construction today.
:[ ... ] is a get-block! (which is not a type today, but it's not a good idea to use this syntax for anything else).
::[ ... ] no no no! :) Not very Rebolish as I see it.
*[ ... ] nah, not a map to me. Might be a future syntax for multiplication of the whole block.
About #[a: 1 b: 2] , I see no point in having to write all the keys as set-words. Map keys can be other types than words - strings for example.
R2 distinguish between keys of type word! and of type set-word! in hash! (old map! type).
The reason for using set-words as keys is, again, for JSON comparison, but also because it makes a lot of sense to normal people. Whether we enforce that strictly in Ren is a good (and hard) question.
I can't imagine what get-block would even mean as a type. Blocks are not evaluated by default.
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.