builtin: add pick(stream)

[pkoppstein]

pick(stream) works on both arrays and objects

Restrictions on the dot-paths are specified in manual.yml

See #2578

[wader]

I wonder if it would make sense to extend the object construction syntax to allow things like {a, b.c, x} to mean {a: .a, b: {c: .b.c}, x: .x}? but would that also work for arrays somehow? would {a[1].b} mean? {a: [.a[1].b] } or {a: [null.a[1].b]}? and what would {a: [.a[1,2].b] } mean? should be in sync with destructing syntax 🤔

Sorry for rambling, maybe i should create a proposal issue to collect ideas if it's something we want to consider? ... also i have no idea about implementation difficulty

[pkoppstein]

@wader - the linked issue already refers to such a proposal, which of course involves an extension to the language, whereas this PR only proposes a builtin, which I think is simple and useful enough to be included regardless of any such extension.

[wader]

@pkoppstein Aha, i see. A nice thing with pick/1 is that things like this works pick(.. | select(...))

[nicowilliams]

Rather than call the thunk stream I'd call it paths or pathexp. After all, it's not used as a stream but rather passed to path/1 which then generates a stream of paths.

[nicowilliams]

I think we want s/stream/pathexp/ here and below, since the closure passed here is passed to path/1, so it's really a path expression.

[nicowilliams]

Don't forget to update the docs to say pathexps.

[nicowilliams]

Apart from proposing s/stream/pathexp/ for the name of the closure passed to pick/1, I like this a lot!

[pkoppstein]

@nicowilliams wrote:

s/stream/pathexp/

How about s/stream/pathexps/ ? I wanted to emphasize the "reduction" aspect of the def, i.e. that the argument is NOT regular.

[nicowilliams]

How about s/stream/pathexps/ ? I wanted to emphasize the "reduction" aspect of the def, i.e. that the argument is NOT regular.

Works for me!

[pkoppstein]

@nicowilliams - Done. Thanks for reminder.

[nicowilliams]

Thanks!