Object composition.

Looks as though Inquiry is a way of feeding JSON to little JavaScript functions. The way the language is designed, both the paths and the JavaScript functions can be compiled. This is a feature to preserve of any sort of extension of the language.

I can see that I wrote it when I wan enamored of the concept of [MicroJS](http://microjs.com/#)) yet I never got around to listing this there. I like that it is lightweight and in a single file, so I’ll continue to strive to keep it small. I believe the restriction imposed by keeping at 1k did a lot to aid the design.

Inquiry would be great to simply pluck values. What’s missing is a way to compose. At this moment I do not need complicated compositions, simply to return a value that is the difference between two values in the object.

What I’m looking to do is to replace a very simple evaluator that I created that runs a function at the root level against an object. This evaluator is supposed to be used to define little actions taken against a stream of JSON log entries, selecting entries based on the truthiness of paths, adding properties to entries, creating new properties through simple arithmetic on other properties.

Creating a duration by getting the difference between two time stamps, would be an example of simple calculations. The presence of a particular string in an array of tags would be an example of entry selection.

For selection, Inquiry is great. There’s no good way to do the modifications though. Inquiry will do projections, but it will always be a subset based on the structure of the existing document.

The first thing that comes to mind is to make inquiry available to the JavaScript function predicates, but that would mean that the source for the Inquiry path is within the JavaScript function and we wouldn’t be able to pre-compile it. We could add caching, but that would be a lot of complexity to prevent leaks caused by running arbitrary, generated paths and growing the cache indefinitely.

Seems that we could use `(` to pass the results of running a path into a predicate. Easy enough to pull out a path from between a matched pair. That is apparently the crux of the parser. The extracted values become the positional (`$1`, `$2`, `$3`) arguments to the function.

`&{ $2 - $1 }(/when)(/done)`

This would be an evolution before a refactor. Ideally, I’d like `{` to be a transform, but I’ve already called an unadorned curly pair a JavaScript predicate. The `&` would means function to me because that’s what it mean in Perl. Could also do:

`>{ $2 - $1 }(/when)(/done)`

Where `>` means a redirection.

Could also do:

`|{ $2 - $1 }(/when)(/done)`

Because that’s what everyone else does, but I don’t like the looks of it, even when I add a gap.

`| { $2 - $1 }(/when)(/done)`

No even when I make it clear that we are piping from one to the other.

`/ | { $2 - $1 }(/when)(/done)`

But, it would be a pipe and it would be called once for each match.

`/presidents | { $0.lastName + ', ' + $0.firstName }`

Actually that looks okay.

`/presidents > { $0.lastName + ', ' + $0.firstName }`

Looks okay too.

So that we might:

`/done > { $0 - $1 }(/when)`

Which is madness, but should be okay.

Nice thing is getting a nice object builder syntax with double curlies.

`>{{ when: $1, duration: $2 - $1 }}(/when)(/done)`

Yeah, like the `>`.