AltME: Ren - Data Exchange Format


It does not looks fine to me... btw, why to have special construct for map! anyway? one can always use:
>> #[map![a 2 b 3]]
== make map! [
    a 2
    b 3
Which leads to question if this would be considered as nice:
#(#[a 1 b 2])
>> #[map![a 2 b 3] is it ok that I can do this?]
== make map! [
    a 2
    b 3
#[#(a 1 b 2)]
"why to have special construct for map! anyway?" To be able for REN to compete with JSON.
#(...) is probably ok for construction syntax, leaving #[...] for maps.
#(#[a 1 b 2]) is not needed anyway, as map! does not support indexes like block! and so it does not have special serialized syntax.
Oldes, the syntax would be simply #(a: 1 b: 2) or #[a: 1 b: 2].
I prefer #[] over #() because maps are really lists. They just have an extra constraint. Technically we don't need them of course. but it does simplify things for generic libraries that would otherwise have to be hinted to create maps in place of lists.
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?

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

(Wow, hi 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.
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)
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.
My whole point is that a set of syntactic rules like:
Space must be significant in
    a / (1 + 1)
    a/(1 + 1)
, or in
    # [true]
, while space must be insignificant in
    a / [1 + 1]
    a/[1 + 1]
or in
    map! [a: 1 b: 2]
    map![a: 1 b: 2]
is not optimal.
I am for consistency, and that is why I wrote, and will support every effort in that direction.
In this case the consistency brings not just the desirable simplicity, but also the flexibility useful for introducing new, demanded types of syntax.

Last message posted 229 weeks ago.