AltME: Ren - Data Exchange Format

Messages

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.
Geomol
About #[a: 1 b: 2] , I see no point in having to write all the keys as set-words. Map keys can be other types than words - strings for example.
R2 distinguish between keys of type word! and of type set-word! in hash! (old map! type).
Gregg
The reason for using set-words as keys is, again, for JSON comparison, but also because it makes a lot of sense to normal people. Whether we enforce that strictly in Ren is a good (and hard) question.
I can't imagine what get-block would even mean as a type. Blocks are not evaluated by default.
I will try to make time to write up a comparison matrix of alternatives. But I'm slammed with work at the moment, so will be happy if someone beats me to it.
Geomol
get-block!
This
    :[a b c]
could mean
    reduce [:a :b :c]
(sometime in the future).
Geomol
I'm not for required set-words in maps. Use contexts (objects), if that's more readable.
I'm ok with both having words and set-words as keys in maps, and maybe they should be different entries into the map.
Gregg
We don't have objects. This is Ren. :-) We also don't have the concept of reduce.
Geomol
I think, you have objects. Ok about reduce, as it is a format. But I see, set-words are planned, so set-blocks may not be ruled out because of some syntax.

Oldes
"About #[a: 1 b: 2] , I see no point in having to write all the keys as set-words. "
I totally agree!... The main purpose of map! is that key may be any (almost?) datatype, not just word!
Gregg
For Ren, then, we need to consider the "almost" part carefully. I agree that being able to use anything as a key value is powerful. What *can't* you use as a key? This is important because the Ren spec needs to be kept a simple as possible, while still allowing much more expressivity than JSON.
From the perspective of data exchange, should there be anything you can't use as a key in a map?
Andreas
I think once we have the syntax settled, we can conceivably deviate between (base) Ren and full Rebol.
Gregg
And, again we're talking Ren here, is this a good thing?
Andreas
In Ren, it may be very useful to restrict potential keys slightly further, to ease interop with other languages.
For full Rebol, we could have slightly more relaxed restrictions.

Last message posted 408 weeks ago.