AltME: Ren - Data Exchange Format

Messages

Gregg
Behavior in the case of extra values in maps needs to be defined. i.e., what's valid or what is silently ignored. It brings up another question though, which I've been thinking about lately.
Do we require an outer container (map or list)? If not, what should the behavior be? If we check for names and matching values, do we have to wait for the end to say it's valid? Some formats are designed to allow streaming. Do we care about that?

Ladislav
My comment:
- I am against changing the existing #[...] construction syntax
- If there is a need to have a new syntax for maps, I would prefer something like ![....], m[...], etc. See http://issue.cc/r3/2094

NickA
(Wow, hi Ladislav)
Ladislav
To explain it further, I claim that Rebol syntax is designed so that
    map! [a: 1 b: 2 c: 3]
should be interpreted as a word followed by a block, while
    map![a: 1 b: 2 c: 3]
should be interpreted as a different type of syntax, where the map! text modifies the meaning.
There are users who claim that this idea is limiting their freedom to require the computer to use the above syntax types interchangeably.
My answer is that Rebol was designed to handle absence (or presence) of space as significant in accordance with existing typographic conventions.
Everybody wanting to have the freedom to leave out spaces where they see fit should turn to a different language.
Cyphre
I like the <datatype>[...] style of syntax due these reasons:
-can be used not only for map!
-won't break the current use of #[...] construct (compatibility)
-extension of the Rebol loader should be efficient and very easy (code for parsing <datatype> should be already here, jest additional check for whitespace or "[" right after)
Andreas
It's evident that Rebol's primary designer did _not_ design Rebol in a way that there is a space required between e.g. a closing and an operning square bracket `][`.
Leaving that discussion aside, the proposed <datatype>[...] has its merits.
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! :)

Last message posted 224 weeks ago.