it's a pipeline operating on a stream of independent json terms. The filter is reapplied to every element from the stream. Streams != lists; the latter are just a data type. `.` always points at the current element of the stream. Functions like `select` operate on separate items of the stream, while `map` operates on individual elements of a list. If you want a `map` over all elements of the stream: that's just what jq is, naturally :)

stream of a single element which is a list:

    echo '[1,2,3,4]' | jq .
    # [1,2,3,4]

    echo '[1,2,3,4]' | jq '.[]'
    # 1
    # 2
    # 3
    # 4
    echo '[1,2,3,4]' | jq '.[] | .' # same: piping into `.` is a NOP:

    echo '[1,2,3,4]' | jq '.[] | select(. % 2 == 0)'
    # 2
    # 4

    echo '[1,2,3,4]' | jq 'map(. * 2)'
    # [2,4,6,8]

    echo '[1,2,3,4]' | jq '.[] | . * 2'
    # 2
    # 4
    # 6
    # 8
    printf '1\n2\n3\n4\n' | jq '. * 2' # same

    printf '{"a":{"b":1}}\n{"a":{"b":2}}\n{"a":{"b":3}}\n' | jq 'select(.a.b % 2 == 0) | .a'
    # {"b": 2}

Hope this helps someone else!

(LLMs are already very adept at using `jq` so I would think it was preferable to be able to prompt a system that implements querying inside of source code as "this command uses the same format as `jq`")

[1] - https://duckdb.org/docs/stable/data/json/overview [2] - https://www.malloydata.dev/

I've observed that too many users of jq aren't willing to take a few minutes to understand how stream programming works. That investment pays off in spades.

Just use jq. None of the other ones are as flexible or widespread and you just end up with frustrated users.

I then switched to JavaScript / TypeScript, which I found much better overall: it's understandable to basically every developer, and LLMs are very good at it. So now in my app I have a button wherever a TypeScript snippet is required that asks the LLM for its implementation, and even "weak" models one-shot it correctly 99% of the times.

It's definitely more difficult to set up, though, as it requires a sandbox where you can run the code without fears. In my app I use QuickJS, which works very well for my use case, but might not be performant enough in other contexts.

  obj.friends.filter(x=>{ return x.city=='New York'})
  .sort((a, b) => a.age - b.age)
  .map(item => ({ name: item.name, age: item.age }));

am I missing something?

Things like https://jsonlogic.com/ works better if you wish to expose a rest api with a defined query schema or something like that. Instead of accepting a query `string`. This seems better as in you have a string format and a concrete JSON format. Also APIs to convert between them.

Also, if you are building a filter interface, having a structured representation helps:

https://react-querybuilder.js.org/demo?outputMode=export&exp...

mapValues(mapKeys(substring(get(), 0, 10)))

This is all too cute. Why not just use JavaScript syntax? You can limit it to the exact amount of functionality you want for whatever reason it is you want to limit it.

Kudos for all the work, it's a nice language. I find writing parsers a very mind-expanding activity.

I implemented one day of advent of code in jq to learn it: https://github.com/ivanjermakov/adventofcode/blob/master/aoc...