Ren: a lightweight data-exchange text format

https://pointillistic.com/ren/

by bananicorn • 9 years ago

92 88 9 years ago

pointillistic.com

bananicorn• 9 years ago

In case anyone wonders - red-lang[0] and rebol[1] both use this notation.

[0]http://www.red-lang.org/ [1]http://www.rebol.com/

92142• 9 years ago

mirror site: http://red.github.io/

grabcocque• 9 years ago

It looks fairly similar to EDN used by Clojure too. Similar, but not, of course, the same.

https://learnxinyminutes.com/docs/edn/

greggirwin18• 9 years 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• 9 years 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• 9 years 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.

92142• 9 years ago

check out Red and Rebol languages:

http://red-lang.org/

http://red.github.io/

http://rebol.com/

I think first version of Rebol interpreter was written in Scheme ;)

protonfish2• 9 years 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• 9 years 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.

protonfish2• 9 years 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• 9 years 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.

dragonwriter3• 9 years ago

Not really; those int types differ in range, but while that matters for a schema format, it doesn't really for an interchange format.

OTOH, exact decimals (of which integers are a subset) differ fundamentally in meaning from limited precision binary (or decimal, though that's more rarely encountered) floating point approximations. Which matters in interchange as well as schema.

jbob20002• 9 years ago

I disagree. For 99% of applications, a number is a number is a number. Integers and floating points are a leaky abstraction, I expect the language/compiler to handle these.

iainmerrick2• 9 years ago

I'd put it at more like 50% of applications.

dmm2• 9 years ago

Try passing around 64bit integers in json. The majority of json implementations only implement double float numbers and will mangle your 64bit ints. The usual solution is passing int64s as strings, nasty.

amyjess2• 9 years ago

The ideal solution is to parse all numbers as a decimal or rational.

(one of my favorite things about Perl 6 is that non-integer literals are rationals by default; floating-point is only used if the literal is specified in scientific notation)

zitterbewegung• 9 years ago

A numeric tower could be useful. https://en.wikipedia.org/wiki/Numerical_tower

vorotato2• 9 years ago

C R Q Z N Complex, Real, Rational, Integer, Natural

greggirwin18• 9 years ago

This comment has generated a lot of interest, and rightly so. The thing to remember is that Ren (and JSON) are data exchange formats, not in-memory representations. If you need more control than their numeric syntax supports, metadata is your friend. Just include that where needed. That doesn't mean every endpoint will honor or treat them the same, of course.

specialist• 9 years ago

"...are data exchange formats, not in-memory representations."

Real world values are still typed.

"If you need more control ... metadata is your friend."

aka implicit user typedefs. Explicit is better.

Yaggo• 9 years ago

Because JSON is a text format, nobody prevents you from encoding floats like this:

{ "int": 1, "float": 1.0 }

Of course it's up to the parser implementation to interpret 1.0 as a float.

The spec is very relaxed about the number type:

https://tools.ietf.org/html/rfc7159#section-6

iainmerrick2• 9 years 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_syntax2• 9 years 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".

vorotato2• 9 years ago

also "Some | None" is a common functional programming idiom.

amyjess2• 9 years ago

It's worth mentioning that Python refers to null as None.

mh-cx• 9 years 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“.

rebolek2• 9 years ago

Yup, the right reason is, that `none` is free in Rebol/Red. Ren is basically nothing else than Rebol/Red syntax under different name. I was of the designers of Ren, it’s been few years, but it’s cool to see it on HN.

greggirwin18• 9 years ago

Noted. Thanks.

rgchris2• 9 years ago

Note that Ren-C (a fork of Rebol that is only tangentially related to Ren) uses `blank` or literal `_`.

The language concept is a bit more fundamental than config files. Rebol (and Ren-C and cousin Red) is a fully homoiconic language that itself has tools for parsing and interpreting DSLs ('Dialects' to use the language's nomenclature) that use the same language rules. In essence you do indeed get the lexer for free.

Would recommend a wee read of: http://blog.hostilefork.com/why-rebol-red-parse-cool/

I've argued that Ren is somewhat redundant as it fills the same space that Rebol does though Rebol lacks a formal specification at this time.

greggirwin18• 9 years ago

Which Rebol fills this space, R2 or R3? The idea was also not loadable Redbol compatibility (which would be nice of course), but general utility. So Ren adds new types and changes others, where it thinks that is best.

vesinisa• 9 years ago

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

draegtun• 9 years ago

Here's a link to a another example - https://github.com/humanistic/REN

kiliancs• 9 years 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• 9 years ago

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

greggirwin18• 9 years 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.

rebolek2• 9 years ago

We agreed on 人, not sure where 仁 came from.

imron3• 9 years ago

not sure where 仁 came from

It means humaneness, benevolence, kindness, and is pronounced exactly the same as 人 which means person/people.

greggirwin18• 9 years 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.

imron3• 9 years 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• 9 years ago

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

perryprog• 9 years ago

Not for me.

doodpants• 9 years ago

The links in the first column under References all have "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.

greggirwin18• 9 years ago

Apologies for that. A lot were just for fun/future ideas. Many links to existing resources on other formats do work.

jepler4• 9 years ago

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

evv• 9 years 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)

jepler4• 9 years 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)

lmm• 9 years ago

In another context it might be cute; with the weeaboo name it's rather horrifying.

greggirwin18• 9 years ago

What do you suggest? ¤ is really the only other option, but $ seems much more universal, if you can choose only one.

rgchris2• 9 years ago

For the most part, Ren is delimited by ASCII characters. Rebol permitted a three-letter code to denote currency: USD$10 GBP$15

pnathan2• 9 years ago

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

greggirwin18• 9 years 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.

pnathan2• 9 years 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.

greggirwin18• 9 years 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 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), 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 to get more information and examples of what it looks like in use.

Cheers.

pdfernhout• 9 years 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.

greggirwin18• 9 years ago

That would be a very different format. A big part of the format is that the lexical forms allow you to write things as you normally would, to another human. That does impose limits, but is part of the fundamental design.

21• 9 years 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.

taeric2• 9 years 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• 9 years ago

Ironically, that is exactly why JSON doesn't have comments: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

greggirwin18• 9 years ago

I agree. I was sad to see comment support removed from the JSON spec.

Ren: a lightweight data-exchange text format

Related Stories