AltME: Ren - Data Exchange Format

Messages

Gregg
All those in favor of #[...] as literal map! syntax and #(...) as construction syntax, say +1. All those against, say -1.
Gregg
Please don't take this to mean that I'm ignoring other points. Ladislav's CC ticket on space significance raises a lot of good questions. I don't know that we need to change anything, but we do need to document it. e.g., in Ren, 'name is defined as [word space] currently, but all Redbol  langs, AFAIK, allow a block or paren to omit the trailing space.
Andreas
Gregg, I think using #[..] as literal map syntax is no longer on the table.
I think the most agreed upon proposal at the moment is to just leave construction syntax as it is, and use either @[...] or @(...) as syntax for maps.
Replace "agreed upon" with "widely supported".
Andreas
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 @(...).
AdrianS
+1 for @[...] or @(...) - I used to be for #[...] too, but for map in particular, the @ is more meaningful for me
Geomol
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.
Gabriele
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.
Gregg
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.
Gregg
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.

Gabriele
For REN the extra #[map! ...] is not a big deal though. Is it?
Gregg
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.
Pekr
what about asterisk? Does it imply multiplication too much? *[a: 1 b: 2]
Geomol
@[ ... ] 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.
Geomol
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).
Gregg
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.

Last message posted 408 weeks ago.