Reusable expressions

[innovate-invent]

With the acceptance of let(), there is the opportunity to introduce user defined functions or reusable expressions.

We already have the expression-type construct, which can be exploited to provide this functionality.

The only additional functionality that would be needed is for an expression-type value to be evaluated when encountered if it was not expected.

for example:

search({"a":{"x":1, "y":1},"b":{"x":2}}, let({func1: &x + y + d, y: 3, d: 4}, &*.func1) -> [6, 9]

In this example let() associates func1 with the expression x + y + d, the literal number 3 with y and 4 with d.
The second argument to let() is expected to be an expression-type and so is handled by let() rather than being implicitly evaluated in place. When the let() expression is evaluated, it projects the remaining expression over the input values. The remaining expression in this case being func1 which is not an identifier in the current context, so it falls back to the identifier defined by let(). The value of func1 is an expression-type, which is not expected at that point, so it implicitly evaluates the expression in-place. let() additionally provides values that are not defined in the context, allowing for definition time values, and evaluation time values. A nested let() could also change the value of y or d if needed.

[jdevillard]

Hello ,

That's a good idea but should the example be :

search(let({func1: &x + y + d, y: 3, d: 4}, &*.func1), {"a":{"x":1, "y":1},"b":{"x":2}}) -> [6, 9]

or I'm missing something?

[innovate-invent]

yep! I think I made a last second change to the values and failed to update it.

[springcomp]

On use case has come up in the Gitter discussions.
Consider the following JSON that represents a nested hierarchy of file system metadata:

{
	"/home/user/Desktop/test_for_chain_click/test": [
		{ "name": "file1", "permission": "0664", "type": "file" },
		{
			"/home/user/Desktop/test_for_chain_click/test/directory1": [
				{ "name": "file2", "permission": "0664", "type": "file" },
				{ "name": "file3", "permission": "0664", "type": "file" }
			],
			"name": "directory1",
			"type": "directory"
		},
		{
			"/home/user/Desktop/test_for_chain_click/test/directory2": [
				{ "name": "file4", "permission": "0664", "type": "file" }
			],
			"name": "directory2",
			"type": "directory"
		}
	],
	"name": "test",
	"type": "directory"
}

Let’s say we wanted to retrieve the list of fully qualified path names for the all hierarchy.
Currently, JMESPath does not allow this, but the let() function would at least allow us to retrieve the list of paths at the top level of the hiearchy. For instance, consider the following expression:

• let( { k: keys(@)[0], v: values(@)[0] }, &v[*].name.[k, @].join('/', @) )

This returns the following list of paths at the top-level:

[
  "/home/user/Desktop/test_for_chain_click/test/file1",
  "/home/user/Desktop/test_for_chain_click/test/directory1",
  "/home/user/Desktop/test_for_chain_click/test/directory2"
]

However, to retrieve files from subdirectories, we need to keep track of additionnal directory metadata.
For instance:

• let( { k: keys(@)[0], v: values(@)[0] }, &{ v: v[?type=='directory'], n:v[*].name.[k, @].join('/', @) } )

Which returns:

{
  "v": [
    {
      "/home/user/Desktop/test_for_chain_click/test/directory1": [
        { "name": "file2", "permission": "0664", "type": "file" },
        { "name": "file3", "permission": "0664", "type": "file" }
      ],
      "name": "directory1",
      "type": "directory"
    },
    {
      "/home/user/Desktop/test_for_chain_click/test/directory2": [
        { "name": "file4", "permission": "0664", "type": "file" }
      ],
      "name": "directory2",
      "type": "directory"
    }
  ],
  "n": [
    "/home/user/Desktop/test_for_chain_click/test/file1",
    "/home/user/Desktop/test_for_chain_click/test/directory1",
    "/home/user/Desktop/test_for_chain_click/test/directory2"
  ]
}

As you can see, the v array contains directory metadata for the second level of the filesystem hierarchy whereas the n array contains the list of fully qualified paths at the top-level of the hierarchy.

Each element of the v array has the exact same shape as the original JSON array.

So, if we had a way to design reusable expressions we could apply that hierarchically.