AltME: Ren - Data Exchange Format


Another thing to consider is, if the output from the contruction interpreter is sent to a code generator, how is MAKE constructed? Using the work, MAKE, isn't good enough, as the meaning of that word could have changed, so maybe something like:
    #[native! make]
or  #[function! make]
or  #[native! 55]
or something
Is it possible to create natives with constructions today, or is it beside the point of this format?
The end of a word is marked by a space, a new line, or one of the following characters:
    [ ] ( ) { } " : ; /
Maybe these shouldn't be in the list to open up for new future syntax rules:
    [ ( { "
It's hard to keep it simple! :)
"I can see why Carl used the construction syntax he did, with blocks as the foundational structure, but I like the feel of #(...) more as I think about it, because of the paren semantics."
I agree on that one. Please, those who work on this and similar formats, consider this deeply! I'm not saying, I'm 100% sure, but it's worth given a great deal of consideration.
And taking the space discussion and construction to the extreme, should these also be considered?
    bitset!#{10101010 ...}
or is it better to create all such constructions with equal syntax, #( ... ) or #[ ... ]
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.)

- `#[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.
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.
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".
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?

Last message posted 230 weeks ago.