AltME: Ren - Data Exchange Format


I'm not sure map![a: 1 b: 2] is that much better than #[map! a: 1 b: 2] (ie, just drop the unnecessary inner block).
if we deem map to be important to be used literally in scripts, then a shortcut makes sense; it's just syntax sugar, nothing else.
I can imagine it being useful, however, since I never used it in practice, it's hard to tell.
I must have missed where #{...] fell out of favor and @[...] was proposed. I'll write out some samples for myself, as I did before, to see how it looks to me. @ doesn't seem more meaningfull right off, but I'll try to keep an open mind (which still likes # being consistently special).
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.
    :[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?

Last message posted 268 weeks ago.