3 ms·

Why? It is, it's just that everything returns a function! The topmost function will in the end be called with the json as an argument. Check out these parts o

Why? It is, it's just that everything returns a function! The topmost function will in the end be called with the json as an argument. Check out these parts of the README: https://github.com/cube2222/jql#attention https://github.com/cube2222/jql#attention https://github.com/cube2222/jql#type-cheatsheet https://github.com/cube2222/jql#type-cheatsheet (elem 0) returns a function which takes a JSON array as input and returns its first element.

michaelmrose 7y ago
Can you find many lisps or even any lisps that evaluate like that? A familiar syntax that actually works different from any lisp in existence may be more hindrance than help.
- scarejunba 7y ago
  It's continuation-passing style.
- kazinator 7y ago
  You can find Lisp macros which evaluate like that, more or less. Programming with combinators over functions is a thing also.
- cube2222 7y ago
  It’s first class functions. Clojure has them. It's just that the query ends up having a type JSON -> JSON, not just JSON.
  - michaelmrose 7y ago
    Take (elem "countries" (elem 0)) Inside out elem 0 has to return a function since it doesn't have enough to do anything. I'm not sure why 0 couldn't be a key necessitating a different function to differentiate but whatever. Elem countries has to return json and one can imagine using the json in the first position like a map in clojure and taking a fn in following position. This would mean that on net it would be exactly the same as. (elem 0 (elem countries))
    - cube2222 7y ago
      It really ends up being called like this: ((elem "countries" (elem 0)) JSON) Yours is more akin to (elem 0 (elem "countries" json)) and you can see that the hierarchy of the query is now inverted in respect to the json. This is what I like about the continuation based approach, a big query will be readable because it fits the data very well.
      - michaelmrose 7y ago
        Is it more readable than (->> JSON (elem "countries") first)
        cube2222 7y ago
        This looks very readable and matches the structure of the json too. To me it's basically the same readability wise with proper indentation. Though with deeply nested data and a lot of map functions I think you'd have a lot of unnecessary (->> JSON ...). But those can probably be eliminated with another macro. Also, there's the pipe function in jql which basically lets you do this.

michaelmrose 7y ago

Can you find many lisps or even any lisps that evaluate like that? A familiar syntax that actually works different from any lisp in existence may be more hindrance than help.

scarejunba 7y ago
It's continuation-passing style.
kazinator 7y ago
You can find Lisp macros which evaluate like that, more or less. Programming with combinators over functions is a thing also.
cube2222 7y ago
It’s first class functions. Clojure has them. It's just that the query ends up having a type JSON -> JSON, not just JSON.
- michaelmrose 7y ago
  Take (elem "countries" (elem 0)) Inside out elem 0 has to return a function since it doesn't have enough to do anything. I'm not sure why 0 couldn't be a key necessitating a different function to differentiate but whatever. Elem countries has to return json and one can imagine using the json in the first position like a map in clojure and taking a fn in following position. This would mean that on net it would be exactly the same as. (elem 0 (elem countries))
  - cube2222 7y ago
    It really ends up being called like this: ((elem "countries" (elem 0)) JSON) Yours is more akin to (elem 0 (elem "countries" json)) and you can see that the hierarchy of the query is now inverted in respect to the json. This is what I like about the continuation based approach, a big query will be readable because it fits the data very well.
    - michaelmrose 7y ago
      Is it more readable than (->> JSON (elem "countries") first)
      - cube2222 7y ago
        This looks very readable and matches the structure of the json too. To me it's basically the same readability wise with proper indentation. Though with deeply nested data and a lot of map functions I think you'd have a lot of unnecessary (->> JSON ...). But those can probably be eliminated with another macro. Also, there's the pipe function in jql which basically lets you do this.