AltME: Ren - Data Exchange Format

Messages

Geomol
And taking the space discussion and construction to the extreme, should these also be considered?
    bitset!#{10101010 ...}
    bitset!"abc"
or is it better to create all such constructions with equal syntax, #( ... ) or #[ ... ]
Geomol
Benefit of equal syntax for all such constructions is, that they become easy to recognize, while given the other possibility too adds flexibility and often less to write.
(There are no constructions in the World language yet. I see benefit in equal syntax across these languages. It will be easier for developers to switch between them for different tasks and/or benefits, each language deliver.)

Gregg
- `#[o [a: 2]]` doesn't seem worthwhile to me.
- Native construction is outside the scope of this.
- I don't want to take anything to the extreme. Let's stay focused if we can.
The question is still what basic construction syntax should look like. If there is value in adding other syntaxes later, we can look at that. For Ren, it's about data exchange. In that context, if it is to support an opaque construction syntax, there should be only one. If we can stick to just that question...
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.

Last message posted 411 weeks ago.