Consider supporting multi-select-list after a projection.

[springcomp]

The grammar does not specify this but the canonical implementation accepts constructs that consist of projections immediately followed by a multi_select_list.

https://github.com/springcomp/JmesPath.Net/blob/d47d83b3dca149a3ffb511be787b93c5b8fabe62/src/jmespath.net.parser/JmesPathParser.cs#L24-L33

Example:

search( *[foo, `2`], {"prop": {"foo": 1}} ) -> [[1, 2]]

Other examples, considering the following input document:

[
  {"age": 20,"name": "Bob"},
  {"age": 25,"name": "Fred"},
  {"age": 30,"name": "George"}
]

Will enable the following expressions and their result:

search( [?age > `20`][name, age], … ) -> [["Fred",25],["George",30]]
search( [*][@.age], … ) -> [[20],[25],[30]]

[innovate-invent]

This is aweful and ugly but I believe we need index-expression

jmespath.spec/GRAMMAR.ABNF

Line 211 in 83a3aa5

index-expression = expression bracket-specifier / bracket-specifier ;; # Index Expressions \

to be

index-expression = ( expression bracket-specifier / bracket-specifier ) [ expression ]

[innovate-invent]

What can't you put on the rhs of a bracket-specifier?

[{
  "foo": {"name": "baz"},
  "bar": {"name": "biff"}
},{
  "foo": {"name": "baz"},
  "bar": {"name": "biff"}
}]

Can you help me make this valid? I am going cross eyed: [*]*.name

Should be able to get ["baz", "biff", "baz", "biff"].

[springcomp]

The problem with bracket-specifier is that is has projections and a singularity, in the form of index = "[" number "]" which does not behave as a projection and thus does not accept the same set of expressions on its right hand side.

[springcomp]

[0]|values(@)[*].name will do what you want.

[innovate-invent]

I updated the data to better illustrate the issue. This needs to be done without referring to any specific index.

[springcomp]

Then… [].values(@)[*].name[] seems to work. 😉

[springcomp]

This is definitely awful and ugly 😁

I think the first question we need to answer is whether this is an intended behaviour or not?

Looking at the Go and Python implementations, this looks likely to be a side effect of introducing the concept of projection into the parsing code itself (whereas this concept is actually not needed just by looking at the grammar – although it is indeed needed at runtime when evaluating the expression and thus, useful as an AST node.)

I think we should simplify index-expression like:

index = "[" number "]"
index-expression = expression index / index

Then, rework – like eliminate – bracket-specifier by introducing the concept of projection into the grammar:

projection =  flatten-projection
projection =/ hash-wildcard-projection
projection =/ list-filter-expression
projection =/ list-wildcard-projection
projection =/ slice-projection

flatten-projection =  "[]"
list-filter-expression =  "[?" expression "]"
list-wildcard-projection =  "[" "*" "]"
slice-projection =  "[" slice-expression"]"

slice-expression =  [number] ":" [number] [ ":" [number] ] 

Maybe even rename list-filter-expression to list-filter-projection to make it more consistent.
But then…

expression =/ ( projection / projection multi-select-list )
expression =/ ( projection projection )

[springcomp]

Hum, I think I disagree.
slices and filters are definitely projections in the sense that the downstream expression is actually evaluated on each item from the list.

Consider:

search( [::][0], [[1], [2, 3, 4]] ) -> [ 1, 2 ]
search( [::].length(@), [[1], [2, 3, 4]] ) -> [ 1, 3 ]
search( [?`true`].length(@), [[1], [2, 3, 4]] ) -> [ 1, 3 ]

[innovate-invent]

I don't think that is wanted, they should just return a list that then can be operated on.
Regardless, if that is how it was implemented then it is a projection.
Flatten-projection is the most surprising to me.

[springcomp]

I agree that we do not necessarily need or want this behaviour.

I‘m trying to understand if this was intended. Of course, both implementations are from the same author so it stands to reason that they exhibit the same behaviour.

I think the JavaScript implementation is special in the sense that this is what people hacking around will experience when trying to create expressions. That’s why I was trying to be as faithful to it as possible when implementing the .NET implementation. Then, I discovered that Go and Python also supported this behaviour.

This awfully looks to me like a bug that now must be turned into a feature. If you see what I mean.

Of course, I’m still speaking from a perspective of absolute backwards compatibility before thinking about deviating from the standard. I appreciate you may be leaning towards a more radical clean-slate approach.

[springcomp]

Flatten-projection is the most surprising to me.

I’m with you on this one.
Actually [] and [*] are behaving in the exact same way for regular arrays.
The actual flattening of arrays seems only useful to me when used as a postfix operator.
I struggle to see a use case, where you woud want to flatten a given input array before operating on it…

[innovate-invent]

I agree that we should at least capture how things actually are, and thank you for doing this.

I am just quite disappointed with the state of the language. My use case has JMESPath as a central technology, with some very non-trivial expressions and these issues are going to be replicated many times over as my users compose paths. I am having to weigh dealing with migrating user data down the road vs the up front cost of re-engineering and implementing a path-spec language.

[springcomp]

See this Gitter thread.