wircho

a quick database for cacheing data temporarily from a web app's client-side code, maybe? I wouldn't make a whole platform depend on it, but seems useful enough at least for prototyping.

Adolfo (the author) here. As I mentioned at the end of the post I want to take this a lot further, even if it's just for fun. I'm thinking of imitating JavaScript's dynamic types with a single type "JS" by overloading subscripts, operators, and using literal convertibles. If someone beats me to it I'll just cite them I guess :)

All the logic is executed on the back-end. Front-end is called only for user input and location.

We've been using this syntax for a while and it works well for us internally, but we're soon releasing more appealing tools. Read comments below for more details.

No. With REL it is possible to aggregate and manipulate any JSON API. The only thing that has to be written in REL is the card file itself. This JSON file is to be hosted anywhere on the web. For example, this is a Hello World card https://gist.githubusercontent.com/wircho/c8f4f5b0ce440b8edd... hosted on GitHub.

If you are releasing a JSON API, I'd be happy to try it out and make a card for it. Let me know if you have more questions!

I would say it's not, since it lacks conditional branching, although one could argue that you can simulate a Turing complete system on a Relevant card by having a user indefinitely tap on a button that refreshes it at the next state.

It's more straightforward than this. Think of it as a more comprehensive Yahoo Pipes or IFTTT, where the nice graphical interface is not yet released publicly. So for now developers can just write the raw JSON. Yes, a LISP interpreter would have done that job (as would a library written in some other programming language). However you are not allowed to download code into an iOS app (precisely for security reasons), and so we're downloading items from a predefined documented list of macros. This simplicity, in turn, makes creating a graphical interface a lot easier, without sacrificing the fact that the structure is as flexible as a functional programming language.

Hi everyone. The author here. A couple of answers to much asked questions:

Why JSON? Mainly because it makes it natural to embed JSON objects into code that's otherwise purely functional. Also, as @detaro pointed out, it saved us the time to build our own parser.

Why not use an interpreter/compiler for an existing functional language? Building our own language allows us to control the reach of the code and prevent malicious stuff. Having our own compiler is also useful when threading and networking matters as much as it does to us, since there is simultaneous front end and back end processing.

The result is a very simple syntax for API aggregation where we take care of all the hard part in the background :)

REL is a fancy JSON syntax for making cards for our recently released Relevant iOS App.

Give it a try and let me know if you have any questions.