Gabriele, the literal map notation is important in Ren. That will leak out to Redbol langs if we want them to understand Ren natively.
Today, I use spec-blocks in R2, and helper funcs for accessing them, but not as much as objects or straight word-value pairs in blocks. I would use them more if they worked like maps. And because the spec block syntax is much nicer for humans (IMO), I then take the extra steps on loading and saving objects to convert them, so config files and such are all basically literal map bodies.
For REN the extra #[map! ...] is not a big deal though. Is it?
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.