AltME: Ren - Data Exchange Format

Messages

Chris
Gregg: I don't know--do you have a reference for the origins of the original specs? Seems beside the point though--to reiterate, there is already more than one island of discussion happening on the formalisation of Rebol (whether that is Ren--if you think of it as such--or just a formalisation of Rebol). Perhaps that's for the best, all told. Just felt it worth pointing out and trying to suggest an alternative.
Petr: rediculous--I've been using AltMe as long as anyone, I'm painfully aware that it's more than 'mostly' a myth.
-- Ridiculous, argh: where's the edit button?
Petr: SO Chat room for [Rebol and Red] (and none of which are Brian D.)
...has 12 owners...

PeterWood
Perhaps the discussion about  using an alternative to AltME could be continued in a more relevant channel. Perhaps self would be appropriate.
Gregg
Thanks Peter.
Gregg
Ren isn't just a formalization of Rebol, since it isn't compatible, though it is in a sense. ren-data.org says what it is, with a strong influence being a desire for interchange between REBOL-like languages.
Pekr
Well, if my understanding is correct, REN has nothing to do with Rebol/Red, apart from being implemented first for the Rebol like languages ....
I have looked at ren-data.org for the first time, and only now I realised, how bad it is :-( Who is this site for? Apart from being aesthetically displeasing (yellow bg color? common), it seems like it is written for the programmers, who know parsers and are supposed to port it to other languages? Not sure this is aproach, which is going to sell the ideas. Such stuff should be imo put into some subsection and front page should be more "marketing" oriented, showing some examples, dialects, without any grammar info ...
Ah, I just got to the json.org site, all clear now. It is terrible, how such popular technology can dare to be represented by such "web site" ... but - that's a different discussion ....
Gregg
Sorry you don't like it Petr, it's all me, but you understand the target audience it's directed at.
Chris
Gregg: despite different end-points, it's likely that 95% (a made-up number) of Ren would be cross-applicable with any formalisation of Rebol, at least as I see it. Perhaps not?
Pekr
I thought, that in regards to Rebol lang ecosystem, it would be 100%?
Chris
Petr: in my mind formalization would be that as I've always seen Rebol primarily as a data format with an informal specification (with a very definite implementation in l-scan.c and to a lesser extent in the Red source tree--if I'm not mistaken in both Rebol 2 and Red/System(?) that is in turn interpreted/compiled). Formalization to me affords a base to make informed changes to the language and to guide de/serializers in other languages. As I understand it, the goals of Ren are similar but with a sense that there are features of the Rebol format that would make implementations in other languages more prohibitive.
(not lesser 'cause it's Red, just because is still in the works :)
PeterWood
One of the bad parts of JSON for me is the hassle of escaping multiline strings when more often the not the JSON is a multi-line string that mustn't have the newlines escaped.
Is is possible to add {} for multi-lined strings?
PeterWood
One comment and two questions about the definition of strings - "A string is a series of zero or more Unicode characters"
1. It would be better to refer to code points than characters.
2. How will the string be encoded? I presume the straightforward is the same as the REN document. (I see that the JSON standard allows for UTF-8, UTF-16 or UTF-32).
3. Will  the ^escaping provided for specifying hex codepoints such as ^(010000) ? If so it will need to be made clear that it  the value of the codepoint is to be supplied (so that people don't escape the UTF-8 for the codepoint be accident.)
PeterWood
I've read the "spec" a bit more thoroughly, the answer is yes. I would like to ask for 2 and 6 digit hex strings to be allowed (for convenience). I think it needs to be noted that the hex number is the number of the Unicode codepoint.
One point about encoding. If the standard states that REN documents must be UTF-8 encoded, that makes life easier for implementors as they don't need to worry about handling the endian issues of UTF-16 and UTF-32.
It is also very good for REBOL3 and Red implementors as both use UTF-8 by default. (Not too good for REBOL 2 though.)
DocKimbel
@Chris We have two lexers in Red, one is written in Rebol for the compiler, one is written in Red (and no more in Red/System) for the runtime part (LOAD support).

Last message posted 160 weeks ago.