11 ms·

Ren: a lightweight data-exchange text format

92 points by bananicorn 9y ago

bananicorn 9y ago
In case anyone wonders - red-lang[0] and rebol[1] both use this notation. [0]http://www.red-lang.org/ http://www.red-lang.org/ [1]http://www.rebol.com/ http://www.rebol.com/
- 9214 9y ago
  mirror site: http://red.github.io/ http://red.github.io/
grabcocque 9y ago
It looks fairly similar to EDN used by Clojure too. Similar, but not, of course, the same. https://learnxinyminutes.com/docs/edn/ https://learnxinyminutes.com/docs/edn/
- greggirwin 9y ago
  Some similarities, but different in that EDN has a tagging approach for some types, and a more limited set of literal value formats.
- frou_dh 9y ago
  It's a shame that EDN never got over the hump in terms of adoption outside of the Clojure community. At least that's my impression.
4lch3m1st 9y ago
The syntax itself reminds me a lot of Lisp (Scheme, specifically) but this is probably on purpose. I wonder if it can be used on Lisps the same way JSON is used in JS.
- 9214 9y ago
  check out Red and Rebol languages: http://red-lang.org/ http://red-lang.org/ http://red.github.io/ http://red.github.io/ http://rebol.com/ http://rebol.com/ I think first version of Rebol interpreter was written in Scheme ;)
protonfish 9y ago
I wish this (and JSON) wouldn't be ambiguous about number type (integers vs. floating point.) There are very different types of data in my opinion.
- neoeldex 9y ago
  They are different data types, but integer is also ambiguous, did you mean signed or unsigned, 32 or 64 bit. Its about your use case, and when your parsing something with loose typing into stricter types, make sure you validate accordingly. But being able to specify the exact type kind of defeats the purpose of an interchangeable data format.
  - protonfish 9y ago
    Yes, the specific type of integer and floating-point can vary, but how operators work and display formatting should be consistent. For example, Modulo should be integer-specific, and the concept of precision only applies to floating-point numbers.
  - cabalamat 9y ago
    > integer is also ambiguous, did you mean signed or unsigned, 32 or 64 bit These are all integers. There only needs to be one integer type for all of: 0 6 -6 8000000000000000000000. Python gets this right.
    - jerf 9y ago
      Now 90%+ of the programming language communities have a bar to implement your specification, because they have to emit a weird type out of the deserializations that will break code in weird ways, and in the case of static languages, you may have created a deserialization format that always emits BigInts (several words of memory and possible a mandatory indirection based on implementation) and will thus be unable to compete on the benchmarks against the serialization formats that specified integer sizes. And your serialization format is that much closer to withering on the vine with no usage. Or you can go the JSON route, mumble your way through the numbers spec, let every language do its own thing, and tell the handful of people seriously interested in moving integers too large to be precisely specified by a 64-bit float to encode as strings or something and stop worrying everyone else with the complexity....
iainmerrick 9y ago
The very first entry in the FAQ ("Why is none used instead of null?") isn't very convincing! It says null "it isn't friendly to normal people who might be given configuration or message files to edit," and gives the example: Children: none Opinions: none That certainly looks pleasant and human-readable, but a bit of a nightmare to interpret! Couldn't it just as well be "Children: 0" or "Children: []"? If the idea is to let non-technical people edit configuration files, the code reading the file will have to be very flexible and forgiving. (Edit to add: maybe that's something you mostly get for free in REBOL? It would be a major headache in most other languages though)
- hood_syntax 9y ago
  Valid points about the ambiguity in that example, but I do believe 'none' is easier to parse than 'null' for the average person. I'm assuming that none is meant to represent, like null "no input was given" not "an input of zero/an empty list was given".
  - vorotato 9y ago
    also "Some | None" is a common functional programming idiom.
  - amyjess 9y ago
    It's worth mentioning that Python refers to null as None.
  - mh-cx 9y ago
    But in that case, wouldn't “unknown“ be even better? I'm not a native english speaker, though, so I may miss some fine nuances in the meaning of “none“.
    - hood_syntax 9y ago
      Disclaimer: this is just my personal views, so I may be missing something here. 'unknown' is almost like saying "We don't know what should be here", while 'none' is closer to saying "We didn't get passed any information here". Ultimately, I feel like 'unknown' is more specific, it conveys intent beyond that of 'none'. Such as, it could imply we actually don't know what kind of data 'Opinions' should hold, rather than that there merely happens to be no data to put there.
vesinisa 9y ago
Easiest way to understand the notation would be to see some examples, but the "Test files" link leads to nowhere.
- draegtun 9y ago
  Here's a link to a another example - https://github.com/humanistic/REN https://github.com/humanistic/REN
- kiliancs 9y ago
  The first thing in a small screen an example. On larger screens it still appears at the top, but floating to the right of the "Goals" section.
faitswulff 9y ago
A different kind of pedantry: which is it, 仁 or 人 ? Both appear on the page and the former seems more fitting.
- greggirwin 9y ago
  Thanks for the input. The idiograms were found based on the Ren name and meaning, but I'm not a native Chinese speaker, so will defer to those who know, and make things clear.
- rebolek 9y ago
  We agreed on 人, not sure where 仁 came from.
  - imron 9y ago
    > not sure where 仁 came from It means humaneness, benevolence, kindness, and is pronounced exactly the same as 人 which means person/people.
  - greggirwin 9y ago
    Without a clear choice (as an English speaker) as to which might be more exact in translation, I think I pulled 仁 in because it also looks like the opening of a block, which is fundamental in Ren.
- imron 9y ago
  When I saw the headline my first reaction was to think "hah I bet it's called Ren because it's a data-exchange format for people", then I saw 仁 and thought - ah that's a much better choice.
mamcx 9y ago
When click into the resources links all open in blank pages?
- perryprog 9y ago
  Not for me.
  - doodpants 9y ago
    The links in the first column under References all have "http://" http://" as their destination. The links in the other columns seem to be fine. Also, the links under Implementations all result in a 404 page.
- greggirwin 9y ago
  Apologies for that. A lot were just for fun/future ideas. Many links to existing resources on other formats do work.
jepler 9y ago
It's cute that the spec believes money is denoted by "$".
- evv 9y ago
  I'm confused.. why is this cute? Of course "$" is used as the symbol for several currencies, but its not clear if you have a better symbol in mind for the generic concept of money. https://en.wikipedia.org/wiki/$_(disambiguation) https://en.wikipedia.org/wiki/$_(disambiguation)
  - jepler 9y ago
    Sarcastically cute. It appears very parochial (in the sense of "limited or narrow outlook") to think that having a single "currency type" is useful, or that using a "$" to denote it is appropriate. While "$" is used by at least one important world currency, I am pretty sure that more people use ¥ than $ by a long shot, and users of € are about as plentiful as people who spend in USD. (The idea that in Rebol one might write EUR$1.00 to denote the value that would usually be written 1.00€ is also pretty horrible)
    - greggirwin 9y ago
      @jepler, 1) Do you agree that a notation should support currency values? That is, they are useful to identify in data, as atomic units? 2) If so, do you agree there should be a single standard symbol and lexical form used to identify them? Because if we don't do that, we have to support every localized notation, correct? 3) If you agree to both of those questions, what symbol do you suggest? ¤ is generic, but not on any keyboard layout I know of. Also, see Chris's note about ASCII priority.
      - juki 9y ago
        > ¤ is generic, but not on any keyboard layout I know of. Finnish (/ Swedish) keyboards have ¤ on `<Shift> 4` ($ is `<Alt Gr> 4`).
pnathan 9y ago
Another go-round, trying to solve the same problem as TOML.
- greggirwin 9y ago
  Not so. From the TOML page: "TOML aims to be a minimal configuration file format." Ren is intended to be a general purpose data exchange format.
  - pnathan 9y ago
    welp, I'm wrong. So it goes. Better reading in the future. :-/ I'll just leave my comment above to not destroy the comment chain.
greggirwin 9y ago
Author of the Ren page being discussed here. Didn't expect to see it on HN. :^) The Ren site (ren-data.org) redirects there, is quite old now, and was a playground and experimental area. Hence the empty links and such. In addition to Bolek's Humanistic repo, I had set up https://github.com/Ren-data/Ren https://github.com/Ren-data/Ren to discuss ideas. Ren is, effectively, Redbol (Red+Rebol). One of the initial goals was to define a subset of values and normalize the syntax (Rebol never formalized its format spec), which could be shared across Redbol langs as they evolved and went in different directions. And also as a bridge for loaders in other languages. JSON has taught us that a small spec is important. The balance between simplicity and expressive value types is key. It may come back to life at some point, but my time was better spent elsewhere for a while. I'm focused on Red now (red-lang.org). It has a native bridge feature for embedding in other langs (https://doc.red-lang.org/en/libred.html https://doc.red-lang.org/en/libred.html), along with a lot more. I believe there is still value in formalizing the grammar so others can create their own implementations, but it's not a priority at this time. In the meantime, you can find the active Red community at https://gitter.im/red/red https://gitter.im/red/red to get more information and examples of what it looks like in use. Cheers.
- pdfernhout 9y ago
  For base types, rather than a set of specific data types which is limited, how about having a standard way to indicate a type and data, like "number:12" and "rational:12/17" and "string:foo" and "date:2017-10-20" and "bitmap-hex:cafebabea2b9c0..."? Then let the reader parse it however they want given their desired interpretation of the type tag. There could be a base set of standard types and ideally an organizational process to add more standard types -- like mimetypes. Mimetypes also might be considered included by default perhaps like "application/json; charset=utf-8:[1, 2, 3]"). It is more characters to include a type for each primitive, but it is more expandable. Likely these files will mostly be generated and read by code anyway, with humans just looking at them now and then for debugging. If that string version seems too cluttery, another option is something like: rational:12/17 and string:foo and string:"this has spaces". Or given possible confusion with maps and colons, another option is rational/12/17 and string/foo and string/"this has spaces" and complex/−1+3i and real:30.564 and "application/json; charset=utf-8"/[1,2,3] and maybe even xml/<foo>bar\ baz</foo> and javascript/console.log("hello") and so on. Or maybe pipes? Like: rational|12/17 and string|foo and string|"this has spaces" and complex|−1+3i and real|30.564 and "application/json; charset=utf-8"|[1,2,3] and maybe even xml|<foo>bar\ baz</foo> and javascript|console.log("hello") and so on.
21 9y ago
I'm annoyed when a text format doesn't support comments. Especially a Human one :) Sometimes you want to comment a section out of a JSON without deleting it. Other times you want to annotate some generated JSON. And because this is a common need, you have ad-hoc unofficial solutions which are not supported by all parsers.
- taeric 9y ago
  In the book Programming Pearls, one of the sections is on "provenance". One of the tips shared was someone that put at the header of every generated file, the command that was used to generate it. I absolutely love the idea and have wanted to do it in places I generate files before. JSON completely kills this, though. I don't want to encode the bloody command, just put a little comment "this file generated on DATE by COMMAND". Grr...
  - alecthomas 9y ago
    Ironically, that is exactly why JSON doesn't have comments: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
    - taeric 9y ago
      Strictly, that is different. He was against parser directives. And offered a solution for the case I gave. Quite frankly, I think this is an area he made the wrong choice on. Which is fine, but still annoying. Like checked exceptions. Logic for the choice was sound, if misguided. End result sucks.
- greggirwin 9y ago
  I agree. I was sad to see comment support removed from the JSON spec.

92 points by bananicorn 9y ago

In case anyone wonders - red-lang[0] and rebol[1] both use this notation. [0]http://www.red-lang.org/ http://www.red-lang.org/ [1]http://www.rebol.com/ http://www.rebol.com/

9214 9y ago
mirror site: http://red.github.io/ http://red.github.io/

grabcocque 9y ago

It looks fairly similar to EDN used by Clojure too. Similar, but not, of course, the same. https://learnxinyminutes.com/docs/edn/ https://learnxinyminutes.com/docs/edn/

greggirwin 9y ago
Some similarities, but different in that EDN has a tagging approach for some types, and a more limited set of literal value formats.
frou_dh 9y ago
It's a shame that EDN never got over the hump in terms of adoption outside of the Clojure community. At least that's my impression.

4lch3m1st 9y ago

The syntax itself reminds me a lot of Lisp (Scheme, specifically) but this is probably on purpose. I wonder if it can be used on Lisps the same way JSON is used in JS.

9214 9y ago
check out Red and Rebol languages: http://red-lang.org/ http://red-lang.org/ http://red.github.io/ http://red.github.io/ http://rebol.com/ http://rebol.com/ I think first version of Rebol interpreter was written in Scheme ;)

protonfish 9y ago

I wish this (and JSON) wouldn't be ambiguous about number type (integers vs. floating point.) There are very different types of data in my opinion.

neoeldex 9y ago
They are different data types, but integer is also ambiguous, did you mean signed or unsigned, 32 or 64 bit. Its about your use case, and when your parsing something with loose typing into stricter types, make sure you validate accordingly. But being able to specify the exact type kind of defeats the purpose of an interchangeable data format.
- protonfish 9y ago
  Yes, the specific type of integer and floating-point can vary, but how operators work and display formatting should be consistent. For example, Modulo should be integer-specific, and the concept of precision only applies to floating-point numbers.
- cabalamat 9y ago
  > integer is also ambiguous, did you mean signed or unsigned, 32 or 64 bit These are all integers. There only needs to be one integer type for all of: 0 6 -6 8000000000000000000000. Python gets this right.
  - jerf 9y ago
    Now 90%+ of the programming language communities have a bar to implement your specification, because they have to emit a weird type out of the deserializations that will break code in weird ways, and in the case of static languages, you may have created a deserialization format that always emits BigInts (several words of memory and possible a mandatory indirection based on implementation) and will thus be unable to compete on the benchmarks against the serialization formats that specified integer sizes. And your serialization format is that much closer to withering on the vine with no usage. Or you can go the JSON route, mumble your way through the numbers spec, let every language do its own thing, and tell the handful of people seriously interested in moving integers too large to be precisely specified by a 64-bit float to encode as strings or something and stop worrying everyone else with the complexity....

iainmerrick 9y ago

The very first entry in the FAQ ("Why is none used instead of null?") isn't very convincing! It says null "it isn't friendly to normal people who might be given configuration or message files to edit," and gives the example: Children: none Opinions: none That certainly looks pleasant and human-readable, but a bit of a nightmare to interpret! Couldn't it just as well be "Children: 0" or "Children: []"? If the idea is to let non-technical people edit configuration files, the code reading the file will have to be very flexible and forgiving. (Edit to add: maybe that's something you mostly get for free in REBOL? It would be a major headache in most other languages though)

hood_syntax 9y ago
Valid points about the ambiguity in that example, but I do believe 'none' is easier to parse than 'null' for the average person. I'm assuming that none is meant to represent, like null "no input was given" not "an input of zero/an empty list was given".
- vorotato 9y ago
  also "Some | None" is a common functional programming idiom.
- amyjess 9y ago
  It's worth mentioning that Python refers to null as None.
- mh-cx 9y ago
  But in that case, wouldn't “unknown“ be even better? I'm not a native english speaker, though, so I may miss some fine nuances in the meaning of “none“.
  - hood_syntax 9y ago
    Disclaimer: this is just my personal views, so I may be missing something here. 'unknown' is almost like saying "We don't know what should be here", while 'none' is closer to saying "We didn't get passed any information here". Ultimately, I feel like 'unknown' is more specific, it conveys intent beyond that of 'none'. Such as, it could imply we actually don't know what kind of data 'Opinions' should hold, rather than that there merely happens to be no data to put there.

vesinisa 9y ago

Easiest way to understand the notation would be to see some examples, but the "Test files" link leads to nowhere.

draegtun 9y ago
Here's a link to a another example - https://github.com/humanistic/REN https://github.com/humanistic/REN
kiliancs 9y ago
The first thing in a small screen an example. On larger screens it still appears at the top, but floating to the right of the "Goals" section.

faitswulff 9y ago

A different kind of pedantry: which is it, 仁 or 人 ? Both appear on the page and the former seems more fitting.

greggirwin 9y ago
Thanks for the input. The idiograms were found based on the Ren name and meaning, but I'm not a native Chinese speaker, so will defer to those who know, and make things clear.
rebolek 9y ago
We agreed on 人, not sure where 仁 came from.
- imron 9y ago
  > not sure where 仁 came from It means humaneness, benevolence, kindness, and is pronounced exactly the same as 人 which means person/people.
- greggirwin 9y ago
  Without a clear choice (as an English speaker) as to which might be more exact in translation, I think I pulled 仁 in because it also looks like the opening of a block, which is fundamental in Ren.
imron 9y ago
When I saw the headline my first reaction was to think "hah I bet it's called Ren because it's a data-exchange format for people", then I saw 仁 and thought - ah that's a much better choice.

mamcx 9y ago

When click into the resources links all open in blank pages?

perryprog 9y ago
Not for me.
- doodpants 9y ago
  The links in the first column under References all have "http://" http://" as their destination. The links in the other columns seem to be fine. Also, the links under Implementations all result in a 404 page.
greggirwin 9y ago
Apologies for that. A lot were just for fun/future ideas. Many links to existing resources on other formats do work.

jepler 9y ago

It's cute that the spec believes money is denoted by "$".

evv 9y ago
I'm confused.. why is this cute? Of course "$" is used as the symbol for several currencies, but its not clear if you have a better symbol in mind for the generic concept of money. https://en.wikipedia.org/wiki/$_(disambiguation) https://en.wikipedia.org/wiki/$_(disambiguation)
- jepler 9y ago
  Sarcastically cute. It appears very parochial (in the sense of "limited or narrow outlook") to think that having a single "currency type" is useful, or that using a "$" to denote it is appropriate. While "$" is used by at least one important world currency, I am pretty sure that more people use ¥ than $ by a long shot, and users of € are about as plentiful as people who spend in USD. (The idea that in Rebol one might write EUR$1.00 to denote the value that would usually be written 1.00€ is also pretty horrible)
  - greggirwin 9y ago
    @jepler, 1) Do you agree that a notation should support currency values? That is, they are useful to identify in data, as atomic units? 2) If so, do you agree there should be a single standard symbol and lexical form used to identify them? Because if we don't do that, we have to support every localized notation, correct? 3) If you agree to both of those questions, what symbol do you suggest? ¤ is generic, but not on any keyboard layout I know of. Also, see Chris's note about ASCII priority.
    - juki 9y ago
      > ¤ is generic, but not on any keyboard layout I know of. Finnish (/ Swedish) keyboards have ¤ on `<Shift> 4` ($ is `<Alt Gr> 4`).

pnathan 9y ago

Another go-round, trying to solve the same problem as TOML.

greggirwin 9y ago
Not so. From the TOML page: "TOML aims to be a minimal configuration file format." Ren is intended to be a general purpose data exchange format.
- pnathan 9y ago
  welp, I'm wrong. So it goes. Better reading in the future. :-/ I'll just leave my comment above to not destroy the comment chain.

greggirwin 9y ago

Author of the Ren page being discussed here. Didn't expect to see it on HN. :^) The Ren site (ren-data.org) redirects there, is quite old now, and was a playground and experimental area. Hence the empty links and such. In addition to Bolek's Humanistic repo, I had set up https://github.com/Ren-data/Ren https://github.com/Ren-data/Ren to discuss ideas. Ren is, effectively, Redbol (Red+Rebol). One of the initial goals was to define a subset of values and normalize the syntax (Rebol never formalized its format spec), which could be shared across Redbol langs as they evolved and went in different directions. And also as a bridge for loaders in other languages. JSON has taught us that a small spec is important. The balance between simplicity and expressive value types is key. It may come back to life at some point, but my time was better spent elsewhere for a while. I'm focused on Red now (red-lang.org). It has a native bridge feature for embedding in other langs (https://doc.red-lang.org/en/libred.html https://doc.red-lang.org/en/libred.html), along with a lot more. I believe there is still value in formalizing the grammar so others can create their own implementations, but it's not a priority at this time. In the meantime, you can find the active Red community at https://gitter.im/red/red https://gitter.im/red/red to get more information and examples of what it looks like in use. Cheers.

pdfernhout 9y ago
For base types, rather than a set of specific data types which is limited, how about having a standard way to indicate a type and data, like "number:12" and "rational:12/17" and "string:foo" and "date:2017-10-20" and "bitmap-hex:cafebabea2b9c0..."? Then let the reader parse it however they want given their desired interpretation of the type tag. There could be a base set of standard types and ideally an organizational process to add more standard types -- like mimetypes. Mimetypes also might be considered included by default perhaps like "application/json; charset=utf-8:[1, 2, 3]"). It is more characters to include a type for each primitive, but it is more expandable. Likely these files will mostly be generated and read by code anyway, with humans just looking at them now and then for debugging. If that string version seems too cluttery, another option is something like: rational:12/17 and string:foo and string:"this has spaces". Or given possible confusion with maps and colons, another option is rational/12/17 and string/foo and string/"this has spaces" and complex/−1+3i and real:30.564 and "application/json; charset=utf-8"/[1,2,3] and maybe even xml/<foo>bar\ baz</foo> and javascript/console.log("hello") and so on. Or maybe pipes? Like: rational|12/17 and string|foo and string|"this has spaces" and complex|−1+3i and real|30.564 and "application/json; charset=utf-8"|[1,2,3] and maybe even xml|<foo>bar\ baz</foo> and javascript|console.log("hello") and so on.

21 9y ago

I'm annoyed when a text format doesn't support comments. Especially a Human one :) Sometimes you want to comment a section out of a JSON without deleting it. Other times you want to annotate some generated JSON. And because this is a common need, you have ad-hoc unofficial solutions which are not supported by all parsers.

taeric 9y ago
In the book Programming Pearls, one of the sections is on "provenance". One of the tips shared was someone that put at the header of every generated file, the command that was used to generate it. I absolutely love the idea and have wanted to do it in places I generate files before. JSON completely kills this, though. I don't want to encode the bloody command, just put a little comment "this file generated on DATE by COMMAND". Grr...
- alecthomas 9y ago
  Ironically, that is exactly why JSON doesn't have comments: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
  - taeric 9y ago
    Strictly, that is different. He was against parser directives. And offered a solution for the case I gave. Quite frankly, I think this is an area he made the wrong choice on. Which is fine, but still annoying. Like checked exceptions. Logic for the choice was sound, if misguided. End result sucks.
greggirwin 9y ago
I agree. I was sad to see comment support removed from the JSON spec.