AltME: Ren - Data Exchange Format


...has 12 owners...

Perhaps the discussion about  using an alternative to AltME could be continued in a more relevant channel. Perhaps self would be appropriate.
Thanks Peter.
Ren isn't just a formalization of Rebol, since it isn't compatible, though it is in a sense. says what it is, with a strong influence being a desire for interchange between REBOL-like languages.
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 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 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 ....
Sorry you don't like it Petr, it's all me, but you understand the target audience it's directed at.
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?
I thought, that in regards to Rebol lang ecosystem, it would be 100%?
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 :)
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?
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.)
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.)
@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).
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.
I think multiline strings offer so much value that we need them. Any strong arguments against?
On encoding, I'm good with requiring UTF8. Any arguments against?

Last message posted 218 weeks ago.