streamich / json-joy

JSON CRDT, JSON CRDT Patch, JSON Patch+, JSON Predicate, JSON Pointer, JSON Expression, JSON Type

Home Page:https://jsonjoy.com/libs/json-joy-js

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

JSON Expressions: Déjà vu (miniMAL)

shirk33y opened this issue · comments

Hi @streamich, such a cool project!

I found this repo lately, when I was searching for "glue" language to integrate app components written in different languages (Python, JavaScript, Java, etc.). I wanted to reuse ACL rules (containing basic logic) across components, define url routing rules in single place and more.
I can understand that this is not the purpose of JSON Expression - it just has to be compact and simple.

What if I told you that in the process I discovered numerous attemps to express complex logic in JSON, however only few of them, instead of more readable objects (such as MongoDB query language), chose arrays as base building block of the algorithm.
I found it super clever, because this is very similar how LISP works, so theoretically it could express algorithtms of any complexity as JSON-serialized AST.

There were attemps. For example math focused interpreter of JSON expressions:

Math JSON:
https://cortexjs.io/math-json/

And bunch of others - mostly domain-specific and very limited.

But what really took my attention for a bit longer was this project:

miniMAL (JSON serialized LISP):
https://github.com/kanaka/miniMAL

Despite being officially a "toy" language, it supports lot of LISP features, it's compact (<1KB) and extendable, it even supports LISP-like macros and tail-call-optimization!

There is even online REPL running in browser!:
http://kanaka.github.io/miniMAL/

In fact - miniMAL is a part of bigger project by the same author:

Make-a-Lisp:
https://github.com/kanaka/mal

It supposed to act as tutorial repo, but as a side-effect,. nearly 100 implementations were created in various programming languages - this is portability I was dreaming of.
Small downside is that it uses it's own LISP like format and each implementation must parse it by it's own, so it might be good idea migrate to JSON Expression - like format - it would greatly reduce boilerplate.

I hope it's not too much hype and chaos from my side :)
I really have a feeling that with little of work it might become something bigger than bunch of PoCs - a simple, hence highly portable and standarized interpreter of JSON Expressions.

Can't wait for your feedback!

And again - kudos for all of those great tools that just suck less.

Best

commented

Hey! Thanks for the links! I've seen Math JSON, it is good to learn about miniMAL and Make-a-Lisp; maybe some functions/ideas could be interesting there.

If it helps, I have documented the syntax in this JSON Expression specification. One follow up I wanted to add is a spec of commonly available operators, i.e. the standard library. Currently the spec just talks about the syntax.

One of the most important considerations in JSON Expression is to make it JIT compilable. The library compiles all expression to a very performant JavaScript code, which is then run through eval. For example expression like ['+', 1, 2] will actually directly compile to 3. Or expression which receives data at runtime like ['+', 1, ['$', '/data']] will be compiled to:

eval('() => 1 + +data0()')