additions to jaq/jaq-std/src/std.jq from jq's builtin.jq about jaq HOT 5 CLOSED

Okay, I can see that INDEX works, but I have no intent of adding SQL-style operators, as written in the README.

Regarding combinations, how did you make these compile in jaq? combinations is defined recursively, so that yields the following error for me:

Error: could not find function
   ╭─[<unknown>:4:22]
   │
 4 │           | (.[1:] | combinations) as $y
   ·                      ──────┬─────  
   ·                            ╰─────── could not find function
───╯

from jaq.

@01mf02 - My apologies for erroneously including combinations. I've added some others that I have tested.

from jaq.

Ok, I have now included normals and finites in 0537323. Thanks for your suggestion!

Thanks also for finding that bsearch compiles correctly; however, because the parser takes too long for my taste to parse such large expressions (~56 seconds on my machine for bsearch, see also #7), I would like to postpone integrating such filters until the parser is faster.

The other filters (IN, INDEX) are SQL-style operators which, as I have already mentioned, I do not wish to include in the standard library (because I do not like some filters to be uppercase, others lowercase etc.).
However, I could imagine something like an sql.jq module for SQL-style operators in the long run; but then, this would not be usable right now because jaq does not support modules.

from jaq.

Just for reference, I have just sped up the parser in 012c9c5, so filters like bsearch should be feasible to implement now.
However, I am more inclined to keep the standard library small, so I do not like to include a filter like bsearch in it.

from jaq.

@01mf02 - Thanks for your careful and considerate explanations. I'm glad you were able to speed up the parser.

Since both IN/1 and INDEX/2 in particular are actually quite important, apart from being useful and widely used, I would like to make a plea on their behalf.

Both are useful and widely used because they are stream-oriented, and in particular because of the efficiency that stream-orientation makes possible. It seems to me that they're also important because they provide convenient access to the stream-oriented foundations of jq. Having standardized definitions of such basic functionality is also very useful. In this regard, I'd like to mention that gojq also supports them.

By the way, neither IN nor INDEX is "SQLish" in any meaningful way, at least that I'm aware of. The choice of uppercase names was evidently largely the result of some poor planning --in and index had already been documented. If you are absolutely opposed to including filters with uppercase names, then I hope you would consider including them but with names to your liking.

The case for bsearch is certainly less compelling, and the jaq-based implementation even more so, but having a simple-to-use and standardized binary search function readily available is often really helpful.

For these reasons, as well as for compatibility with both jq and gojq, I would ask that you reconsider their inclusion.

(If the implementation of bsearch in jaq turns out to be unsatisfactory, it could always be replaced by one written in Rust :-)

Thanks!

from jaq.