AltME: Ren - Data Exchange Format

Messages

Andreas
For compatibility reasons, it's also pretty easy to conceive a slightly modified variant, of <typename><sigil>[...], which would side-step the space significance discussion and trade it against a "potentially slightly reduced set of valid characters in words" discussion.
Ladislav
My whole point is that a set of syntactic rules like:
Space must be significant in
    a / (1 + 1)
versus
    a/(1 + 1)
, or in
    # [true]
versus
    #[true]
, while space must be insignificant in
    a / [1 + 1]
versus
    a/[1 + 1]
or in
    map! [a: 1 b: 2]
versus
    map![a: 1 b: 2]
is not optimal.
I am for consistency, and that is why I wrote http://issue.cc/r3/2094, and will support every effort in that direction.
Ladislav
In this case the consistency brings not just the desirable simplicity, but also the flexibility useful for introducing new, demanded types of syntax.
Oldes
image![1x1 #{000000}]   is not bad... I like the <datatype>[...] idea.
Where not it's in this not pretty form:
>> make image! 1x1
== make image! [1x1 #{
000000
}]
Oldes
(where not = where now)
Cyphre
...and you could still use as alternative: #[image! 1x1]
Oldes
which is imho the best:)
Gregg
The CC ticket has good discussion on the space-significance issue. On construction syntax, Ladislav's suggestion (map![a: 1 b: 2 c: 3]) is cleaner than the current syntax (#[map! [a: 1 b: 2 c: 3]]), but we don't commonly need construction syntax for most datatypes. Map! is the big one. In that case, Using the # sigil aligns with it being used as a special content marker (#[ ], #{ }, #" ").
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.
The `<datatype>[...]` syntax doesn't grab me right now.
A key question is whether Ren should support construction syntax of any kind. The other key issue in the CC ticket is path values, which Ren only supports a simple version of so far, in the spec, i.e., no parens allowed.

Geomol
If a construction
    #[<value1> <value2> ...]
is simply interpreted as
    make <value1> [<value2> ...]
, should this then be allowed:
    o: make object! [a: 1]
    #[o [a: 2]]
Geomol
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?
Geomol
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! :)
Geomol
"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.
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.

Last message posted 183 weeks ago.