streamich / json-joy

JSON CRDT, JSON CRDT Patch, JSON Patch+, JSON Predicate, JSON Pointer, JSON Expression, JSON Type
https://jsonjoy.com/libs/json-joy-js
Apache License 2.0
697 stars 11 forks source link

JSON Expressions: Déjà vu (miniMAL) #648

Open shirk33y opened 2 weeks ago

shirk33y commented 2 weeks ago

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