AltME: Ren - Data Exchange Format

Messages

Chris
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).
Gregg
Pekr, It can never be 100%, as R2, R3, Red, World, etc. all differ somewhat.
Chris, right.
Peter, I want multiline strings as well. Initially I tried posting proposals, building up from base types, to try and gain consensus. Didn't work so well. So consider the current spec to have gaps. I will adjust the text to refer to code points. On convenience, which applies to multiline strings as well, Redbol compatibility is a primary concern, but also keeping the rules as simple and unabmiguous as possible. Unicode isn't my area, so I will defer to you and others on cost/benefit.
To Petr's (Pekr) point about hiding the grammar on a detail page, I did just recently think about doing something like that. Not entirely, but leaving out sub-rules like int, frac, exp, etc. since the main page is just informative. That is, just list the top-level types.
However, the page was intended, as Petr so astutely observed, for the people who might implement parsers and generators for it. The idea being to have a single page that offers a description and reasoning for each datatype, with the informative grammar right there as well.

Last message posted 172 weeks ago.