AltME: Ren - Data Exchange Format


Replace "agreed upon" with "widely supported".
So, -1 from me on shuffling things around to use #[...] as map! syntax and #(...) as construction syntax.
While I still like the idea of parens for construction syntax, I don't think the compatibility issues are worth the hassle. Neither is it necessary (or worth it) to free up the literal space for map, because we have a similarly nice-looking but non-breaking proposal on the table, which is @[...] or @(...).
+1 for @[...] or @(...) - I used to be for #[...] too, but for map in particular, the @ is more meaningful for me
I need to implement and use a dedicated map! syntax in World to really have an opinion. Practical use sometimes reveal some issues. I like @[...]Êbetter than @(...) for map! , as I like #(...) better than #[...] for contructions, but as I haven't used constructions much, leaving it as it is for now is ok. When I come to implement constructions in World, I will have to figure it out, maybe even implement both syntaxes for a period as a test of usage.
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.

Last message posted 229 weeks ago.